I am working on a Swing application and would really love to declare my views in an XML format in fashion similar to GWT's UiBinder, JSP, JSF, ZK, IceFaces, etc.
I found JFCML but it doesn't appear to be an active project; in terms of development as well as use/reference.
Have my Google skills failed me or does something like this not exist? If it doesn't exist, is it because such methods of separating view and controller are better done another way in Swing?
The "built-in" solution is the XMLEncoder - XMLDecoder pair, but they are not widely used, I am not sure that they can cope with real-world scenarios.
A lot of open-source libraries have been suggested already on SO, I recommend these questions:
suggestions for declarative GUI programming in Java
Java: Create a GUI with XML?
Is XML or XUL the future of Java GUI building?
Java form from xml
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
Hey guys I have been trying different Javascript/AJAX jsf frameworks. I find most of them extremely heavy. Icefaces tends to add so much javascript just for simple things and it uses a notoriously slow javascript framework also. Primefaces is a little better since it uses jquery but I still find it kind of heavy. What if I just want to use straight vanilla jsf and add javascript on top of that.
What is the best way to go about this. I would need to be able to output javascript to the page from the backing bean. Would a servlet or restful service be good way to output javascript/html to a page?
I basically want to use basic jquery animations. Maybe do a datatable filter. Thanks for any help.
What you want is definitely supported in JSF. You can use the <h:outputScript> tags for this and additionally the <h:outputStylesheet> tag if you also need CSS.
With these tags you can include scripts per view (page), although you can also opt to include them for all pages by creating a master Facelets template and include those there.
You can also create very simple components of your own by using JSF/Facelet's composite component feature. Those components just consist out of a simple .xhtml template file and those can include the javascript libraries you need and contain your own lightweight tailor-made javascript.
See this for some examples of using the <h:outputScript> tag in JSF: http://www.mkyong.com/jsf2/resources-library-in-jsf-2-0/
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 have a bunch of JSP files and backend in Tomcat. I have 3 different versions of JSP with same logic inside but with different layouts. So if I change some logic I have three JSP file to fix.
What is the proper soution for such a scenario? I thought of some XML and XSLT stack: backend gives only data in XML and than for each layout I have XSLT that does some magic.
Just imagine that you need to provide stackoverflow in various languages in JSP. Logic the same but layout different.
Could you point me into some direction?
Learn about MVC (Model View Controller) and the idea that JSP should be the View part of it and should not contain any logic whatsoever. Logic belongs in a Model class.
This is usually solved by using some templating engine - you create smaller page fragments, and then you declare to the template engine that certain views should consist of these parts, put together in a certain way.
Struts tiles is the classic example in the Java world, but it is really getting old and crufty compared to more modern framworks in Java and other languages. Tapestry and Wicket are two more modern ones (haven't used them though).
For only 3 pages applying a whole web framework is probably overkill though, but if your site grows...
With plain old JSP without any kinds of fameworks:
1)
Use controllers to do the processing and only use jsp to display the data
2)
Use jsp include directives to include header, navigation, menu, footer and other necessary common/shared elements to all of those layouts.
Or/and:
Use the following in web.xml
<jsp-property-group>
<url-pattern>/customers/*</url-pattern>
<include-prelude>/shared/layout/_layout_customers_top.jsp</include-prelude>
<include-coda>/shared/layout/_layout_customers_bottom.jsp</include-coda>
</jsp-property-group>
The url pattern determines which jsps get which jsp fragments (partials in Ruby on Rails) attached to top/bottom.
Take a look at Tiles.
This is a very classical problem domain and there lots of concepts and frameworks out there that are trying to deal with this issue (MVC frameworks like Struts and JSF, SessionBeans to name but). As I suspect you're not really a Java enterprise "evangelist" I will give you 2 simple advices.
You obviously have a lot of redundant code in you're JSPs. Extract this code into "real" Java-Classes and use them on all of your JSPs. That way you will be able to modify business logic in one place and redundancy will be less of a problem.
Take a look at Cascading Style Sheets (CSS). This is the state of the art way to layout webpages. You may not even need different JSPs for different layouts, if you have well designed html + CSS.
Regards