I am wondering what the best practices in developing an application where an external CSS developer is involved in designing the look and feel of the site?
Ideally, they would be creating CSS files that we could easily integrate into the site over multiple iterations, and the development team would not have to do any manipulation of these files (obviously there would be HTML or template changes to point to the appropriate classes).
GWT documentation (http://code.google.com/webtoolkit/doc/latest/DevGuideUiCss.html) lists four approaches:
Using a tag in the host HTML page.
Using the element in the module XML file.
Using a CssResource contained within a ClientBundle.
Using an inline element in a UiBinder template.
The documentation suggests that modern applications would tend to use approaches 3 and 4, however these seem intrusive to the development process, as we do not want to have to constantly update CssResource interfaces with changes to the CSS each iteration (in approach 3) or have to chop and split the CSS files to inline them into our ui.xml files (in approach 4).
We are thinking of using approach 2, and hand coding the CSS classes. This would allow us to easily drop in CSS file updates and not have the developers need to touch them. We would lose obfuscation and there would be some work to manage changes to CSS names, though no more than the other approaches. Are there any other considerations I am missing?
Is there a best practice for building GWT applications where external CSS designers are involved?
There can be issues if you have team who is not conversant in both HTML/CSS/JS & GWT/Java. Let's assume you have rock starts, which you should strive for. Then you want to get the following CSS GWT benefits:
No string literal class name references
No CSS namespace conflicts/pollution
Minimization of CSS classes (compress selectors and properties)
Compiler optimization of CSS rules (combine similar rules), exclusion of unused rules
Compiler time checking of CSS validity and missing classes
No heap of external CSS files
No issues when running DevMode in remote mode (otherwise browser pulls remote CSS, not new CSS you're working on)
I find the best way to do so is with the UiBinder & the Java class for that UiBinder, all in one place. See below example. This will in my experience produce the most robust, compressed, fastest, reliable app possible, and adds no additional files.
Everything is in one place:
CSS defined in UiBinder, where it's used
CSS interfaces defined in Java file, where they're used
Widget
class MyClass extends Widget {
... // jave UI binder class
public interface MyStyle extends CSSBundle {
String someClassName();
}
#UiField
MyStyle style;
...
something.setClassName(style.someClassName());
...
}
UiBinder
<!-- UiBinder File -->
<ui:UiBinder xmlns:ui='urn:ui:com.google.gwt.uibinder'>
<ui:style type='com.my.app.MyFoo.MyStyle'>
.someClassName { background-color:pink; }
</ui:style>
<div class='{style.someClassName}'>Sample text.</div>
</ui:UiBinder>
I've asked this question before, check it out here.
It's very hard to have a "best practice" here as the four different approaches work well in different situations. Depending on how you use GWT, will determine the best option to use.
If your team is made up of A) Java-only and B) CSS/HTML only, options 1 or 2 will work. However, if you have a UX role who understands the integration point of GWT and CSS/HTML/XML (read: UiBinder). This person may understand how to best set up a UiBinder inorder to maximize the functionality give to the Java-only role.
UiBinder + ClientBundle add an extra layer of complexity to your project. With this comes many advantages, but if your team is'nt a good fit you may end up causing too much harm.
A "Best Practice" may included organizing a main CSS file (either used via ClientBundle or options 1 or 2) that is organized in a way that gives the overall application consistency while at the same time using specific styling in UiBinders for local stuff
If you want to go all out, I think you should focus on using UiBinder and CssResource/ClientBundle to the max (Externs CssResource/ClientBundel stuff as well as giving programmatic access to UiBinder styles via
Use the external stuff for reuse + added consistency
Related
Got three questions on the play Scala template system.
Just a clarification:
I am assuming you create a new template for each kind of page that you want to produce - that correct? So, a log in page, an accounts page, home page, etc? Does this mean I should expect to have quite a few templates?
If I am say storing a history of orders - using java OO features with classes such as OrderLog and order. Would it be ok to call a java method in OrderLog.java that directly creates html text that I simply pass to the Scala template or is this a bad idea? Should I instead give the objects to the Scala engine and have that translate them?
The two considerations I am thinking of are whether the Scala is faster at rendering the text and whether it is just bad style to have the java compose the string.
How do I render JSP using the play framework?
For good design and ease of use, you'd probably want a modular design, where repeated structures (such as a footer for instance) have their own templates. Sometimes a large portion of multiple different pages could be reused, where you should only write it down once in a template that you use on all pages (can also parametrize your template to serve two almost similar pages). Thus, you should create plenty of templates. Think about them as methods in your code, helps being DRY (Don't Repeat Yourself) and KISS (Keep It Simple Stupid), not trying to solve all the problems in one template or forcing every page to have their own template that does practically same things as another page.
According to the MVC pattern, you should leave all rendering details for the views (in this case your templates) and keep it out of your models (OrderLog). Should be less verbose to do it in a template than trying to create HTML on server side and all your HTML is in one place, so it's clearer for new people - or yourself after a long break from working with this application.
You shouldn't use JSP, just the template engine. It can do everything plain JSP's would and more. Templates will be rendered when you have the server up and running and load the pages (on dev mode). You can keep changing POJO's or templates without having to republish the application or restart the server to see the differences.
For GWT we use static constants to provide internationalization for our users. However, this makes reviewing and editing the texts a tedious process, because if one of our stakeholders has comments, it has to be compiled and deployed to our demo environment again. The solution would be to have some kind of semi dynamic text constants.
What I would like, is that I can compile to some kind of "review mode", and when I do that, the constants are read from a file from the server or database. If possible I would like to be able to edit this file, so stakeholders can modify the texts themselves (using some kind of text edit widget I would have to write for that). Then we can develop, test and demo with these texts. If we are satisfied, we compile for production mode, which uses a old fashioned constants resource bundle, compiled completely in JavaScript.
Does somebody know if something like this exists, or have some pointers on how to implement this?
It is a very surprising situation that GWT programmers often overlook the usefulness of JSPs and the Dictionary class. Even though many of us had tons of JSP experience prior to using GWT.
Dictionary class
You can define your "static" information as javascript var objects in the html hosting file. The Dictionary class can be used to read those javascript objects any time after moduleload.
JSP
The HTML "hosting" file, i.e. the html file used for launching GWT need not be an HTML file. It can be a HTML file dynamically generated by a JSP.
If you are familiar with JSP, you could turn an HTML file into a JSP just by changing its extension. Now turn the javascript object section you used for defining GWT "static" information into being dynamically generated by the JSP.
Voila!
I use JSP as the hosting file when I need to generate user- or session- specific "static" information for the GWT client. The JSP could read from the database or from some conditionally chosen text files.
I've downloaded primefaces sources to see if I can learn from them. The jar contains a bunch of java classes that use writers to handle the rendering etc. I was expecting to find some .xhtml files with
<ui:composition> ... </ui:composition> and <cc:interface> etc etc
Anyway this got me thinking, is there another way to write facelets and composite components or they wrote everything in xhtml files then compiled them to java classes? Sorry if my question is absurd I am new to JSF.
Template files and composite components are just for enduser's convenience because it's easy to write and use them. The basic JSF implementation (the f: and h: components) and component libraries like PrimeFaces use fullworthy UI components. That are classes which extend JSF UIComponent class.
Development of UIComponent classes is relatively complex and clumsy. You've got to take a lot of things into account when developing them, such as writing tag files (you've to define every attribute in a XML file), configuration files (link component and renderer with each other), etc, but you end up with a more modular and reuseable model and better efficiency. They are even useable on plain old JSP files.
Facelets templates are unlike JSP files not compiled to Java classes. They're just loaded and executed by a SAX (XML) parser which is by itself already written in Java.
Update as per the comment: it will in general perform a tad better if there is relatively a lot of business/conditional logic involved which is in no way related to the view, such as a heap of <c:if>, <c:choose> etc tags based on non-user-controlled input.
The book JSF 2.0 The Complete Reference also covers custom UIComponent development in chapter 10 "Noncomposite components". The Java EE 5 tutorial covers it as well, but it's targeted on JSF 1.2. It's unfortunately not in Java EE 6 tutorial for JSF 2, although the technique has not changed, but there are several new annotations which you need to know about.
One more advice in case you want to patch around in the sources of primefaces2. It uses a org.primefaces.maven-jsf-plugin which generates many of the .java files. I once tried to patch one of them and I was surprised that the change always was lost after a mvn package
I'm about to choose to way to organize my view (with spring-mvc, but that shouldn't matter much)
There are 6 options as far as I see (though they are not mutually exclusive):
Tiles
Sitemesh
Freemarker
Velocity
<jsp:include>
<%# include file="..">
Tiles and Sitemesh can be grouped; so can Freemarker and Velocity. Which one within each group to use is not a matter of this discussion, there are enough questions and discussions about it.
This is an interesting read, but can't quite convince me to use tiles.
My question is - what do these frameworks give that can't be properly done with <# include file=".."> and JSTL. Main points (some taken from the article):
Including parts of pages, like header and footer - there isn't a difference between:
<%# include file="header.jsp" %>
and
<tiles:insert page="header.jsp" />
Defining parameters in the header - like title, meta tags, etc. This is very important, especially from SEO point of view. With the templating options you can simply define a placeholder which each page should define. But so you can in jsp with JSTL, using <c:set> (in the including page) and <c:out> (in the included page)
Layout reorganization - if you want to move the breadcrumb above the menu, or the login box above another side-panel. If page inclusions (with jsp) is not well organized, you might need to change every single page in such cases. But if your layout is not overly complex, and you put the common things in header/footer, there is nothing to worry about.
Coupling between the common components and the specific content - I don't find an issue with this. If you want to reuse some fragment, move it to a page that doesn't include any header/footer, and include it wherever needed.
Efficiency - <%# include file="file.jsp" %> is more efficient than anything else, because it is compiled once. All other options are parsed/executed many times.
Complexity - all non-jsp solutions require additional xml files, additional includes, pre-processor configurations, etc. This is both a learning curve and introducing more potential points of failure. Also, it makes support and changing more tedious - you have to check a number of files/configurations in order to understand what's happening.
Placeholders - do velocity/freemarker give anything more than JSTL? In JSTL you put placeholder, and use the model (placed in request or session scope, by controllers) to fill these placeholders.
So, convince me that I should use any of the above frameworks instead of/in addition to plain JSP.
A few arguments for Velocity (I haven't used Freemarker):
Potential to re-use templates outside of a web context, such as in sending emails
Velocity's template language syntax is far simpler than JSP EL or tag libraries
Strict separation of view logic from any other sort of logic - no possible option to drop down to using scriptlet tags and doing nasty things in your templates.
Placeholders - do velocity/freemaker give anything more than JSTL? In JSTL you put placeholder, and use the model (placed in request or session scope, by controllers) to fill these placeholders.
Yes, references are really the core of VTL:
<b>Hello $username!</b>
or
#if($listFromModel.size() > 1)
You have many entries!
#end
Efficiency - <%# include file="file.jsp" %> is more efficient than anything else, because it is compiled once. All other options are parsed/executed many times.
Not so sure I agree with or understand this point. Velocity has an option to cache templates, meaning the abstract syntax tree they are parsed into will be cached rather than read from disk each time. Either way (and I don't have solid numbers for this), Velocity has always just felt fast for me.
Layout reorganization - if you want to move the breadcrumb above the menu, or the login box above another side-panel. If page inclusions (with jsp) is not well organized, you might need to change every single page in such cases. But if your layout is not overly complex, and you put the common things in header/footer, there is nothing to worry about.
The difference is, with a JSP approach, wouldn't you be re-organzing this layout in every JSP file that uses the same header/footer? Tiles and SiteMesh allow you to specify a base layout page (JSP, Velocity template, etc - both are JSP frameworks at their heart) where you can specify whatever you want and then just delegate to a "content" fragment/template for the main content. This means there would be just one file to move the header in.
The choice between jsp:include and Tiles/Sitemesh/etc is the choice between simplicity and power that developers face all the time. Sure, if you only have a few files or don't expect your layout to change very often, then just use jstl and jsp:include.
But applications have a way of growing incrementally, and it can be hard to justify the "stop new development and retrofit tiles (or some other solution) so we can fix future problems more easily", which is required if you don't use a complex solution in at the start.
If your sure your application will always remain simple, or you can set some benchmark of application complexity after which you will integrate one of the more complex solutions, then I'd recommend not using tiles/etc. Otherwise, use it from the get-go.
I'm not going to convince you to use other technologies. For all I know everyone should just stick to JSP if it works for them.
I work mainly with Spring MVC and I find JSP 2+ in combination with SiteMesh the perfect match.
SiteMesh 2/3
Provide decorators to be applied to the views mostly like inheritance works in other templating engines. Such feature is unthinkable to work without nowadays.
JSP 2+
People claiming that JSP will make it hard to avoid Java code in templates is bogus. You just shouldn't do it and with this version it's unnecessary to do so. Version 2 supports calling methods using EL which is a big advantage compared to previous versions.
With JSTL tags your code will still look like HTML so it's less awkward. Spring packs a lot of support for JSP through taglibs which is very powerful.
The taglibs are also easy to extend so customizing your own environment is a breeze.
One of the best arguments for facelets (not in your list, but I'll just mention it) opposed to using JSP is that the compilation is integrated with the interpreter instead of being delegated to the JSP compiler. This means that one of the most annoying things I had with JSF 1.1 - having to change the id-attribute on a surrounding JSF-tag when saving a change in order for the runtime engine to discover the change - went away, giving the save-in-editor, reload-in-browser cycle back, along with much better error messages.
A good view technology eliminates most and most anoying if/switch/conditional statements, simple include does not. Using a 'complex' view technology results in a 'simple' application.
You didn't provide information about specific of your applications. For example I do not use JSP just for few reasons:
It is hard to avoid using Java code in JSP templates so your break concept of pure View, and as result you will have difficulties to maintain code in several places as view and controller
JSP automatically creates JSP context which establishes a session. I may want to avoid it, however if your applications always use session it can be not a problem for you
JSP requires compilation and if target system doesn't have Java compiler, any minor tweaking will require to use other system and then redeploy
Minimal JSP engine is about 500k of bytecode plus JSTL, so it can be not suitable for embedded systems
Template engine can generate different content type of the same model, let say JSON payload, webpage, e-mail body, CSV and so on.
Non Java programmer may have difficulties to work with JSP templates, when non technical people never had difficulties to modify regular templates.
I was asking same question long time ago and ended by writing my framework (surely template engine based) which was free from all disadvantages I saw in other solutions. Needless to say it is about 100k of byte code.
I realize that this comes off as a smart ass answer, but the truth of it is, if you don't see any advantage to using templating over code in your current project, it's probably because in your current project, there isn't one.
Part of it is about scale. You might think that includes are every bit as powerful as let's say sitemesh, and that's certainly true, at least for a small number of pages (I'd say probably about 100), but if you have several thousands it starts becoming unmanageable. (So for eBay it's not necessary, for Salesforce it probably is)
Also, as has been mentioned before, freemarker and velocity are not servlet specific. you can use them for anything (mail templates, offline documentation, etc.). You do not need a Servlet container to use freemarker or velocity.
Lastly your point 5 is only partially true. It is compiled every time it is accessed if it has not been so already. This mean that whenever you change something you need to remember to delete your servlet containers "work" directory, so that it recompiles the JSP. This is unnecessary with a templating engine.
TL;DR Templaing engines were written to address some (perceived or real) shortcomings of JSP + JSTL. Whether you should use them or not depends entirely on your requirements and the scale of your project.
I've never used Java before (C# is my domain), but now I have a task that I must apply a specific style to for a tiny Java webpage. The style is from another ASP.NET application that we're rolling out and that I've helped to develop. Seems that this style is on the way to become our new company web-style. :P
The webpage is really tiny - it has only a login form and an action form with a dozen textboxes and a button. When you click the button, a file is generated and available for download.
This application has already been made by a colleague of mine, who has good experience with Java, but nearly no experience with the web. So he's no help anymore. For now the application has NO style at all. Just a bunch of textboxes.
The application is made in NetBeans and Java Faces - as far as I understand. Or maybe it's "Visual Faces". Not sure - can't make heads or tails with all these names from the Java world. Anyway, it's this ASP.NET look-alike where you have an XML page with tags like <ui:textField> and <ui:passwordField>, and then a code-behind file with all your Java code. (Actually I suspect that ASP.NET was created after this, but that's besides the point)
I've successfully converted the HTML layout to the one I need and set my own CSS/JavaScript files in the header. There's just one problem - the Faces thing is hell-bent on including its own CSS stylesheets as well. Sounds reasonable of course, but for some mind-boggling reason these stylesheets also deem it necessary to override styles on all the common tags - <body>, <div>, <span>, etc. Which is annoying, because that breaks my design. Now, I could change my own stylesheets to over-override these default Faces stylesheets, but that seems... well, not the right solution. It's like a workaround, not a "correct" solution. Why should I redefine font attributes for every tag, when it should easily cascade down from the "body" tag?
Is there any way how I can tell Faces not to include its own stylesheets? I won't be using any of their controls anyway - just textboxes and buttons. And labels, when I find them. :P
Oh, yes, and I tried to re-create it all in simple JSP (no Faces), but that failed, because the code-behind (there's some big library there) is dependent on it... This is also the reason why I can't move it to the ASP.NET I'm so familiar with.
Added: Since it seems there are many Java Faces frameworks out there, here's a snippet of code that might help:
<jsp:root version="1.2" xmlns:f="http://java.sun.com/jsf/core" xmlns:h="http://java.sun.com/jsf/html" xmlns:jsp="http://java.sun.com/JSP/Page" xmlns:ui="http://www.sun.com/web/ui">
<jsp:directive.page contentType="text/html;charset=UTF-8" pageEncoding="UTF-8"/>
<f:view>
<ui:page id="page1">
<ui:html id="html1">
<ui:head id="head1">
Also I forgot to mention that there is a folder in NetBeans called "Sun Web UI Components Themes" which has three items under it - "Gray Theme", "Green Theme" and "Default Theme". I can choose one of them as the active one, and that also changes the CSS which is included by default. Unfortunately I cannot choose none.
OK, I already changed my style to override these stylesheets. Still it would be nice to hear more about what I'm dealing here with. I don't even know where I should look for documentation...
Added 2: Also, the namespace for say, TextField, is com.sun.rave.web.ui.component.
Which JSF (JavaServer Faces) library is this using? MyFaces? RichFaces? Something different?
I don't know if you've found this resource yet: JSF Tag lib.
If it's using <ui: type tags, then it's also using Facelets which is a templating system for JSF. However the tag parameter you are probably looking for is styleClass and Style.
There really isn't a default styling for standard JSF, and I think there's probably another JSF library that's being used. Under the WEB-INF directory is probably a directory called lib where the jar files are. Those should give you a clue as to what library's are being used.
RichFaces comes with its own styling, and is completely themeable. In your particular case, it's going to be more of a pain than it's worth for your situation. Other JSF library's may do the same.
Unfortunately I can only point you at places and ideas of where the problem might be. Given the vast number of choices when it comes to JSF, it's the best thing I can do.