Den 21/04/10 19.22, Aaron Bartell skrev:
Could you expound? I used the initial JSF release and liked some parts a
lot and others were productivity drainers.
I can try. I am still in the migration phase of an existing
application, and it is tiny, tiny steps, but I have already gathered a
few experiences.
* First of all, JSF does not work well with JSF. The two are not
properly woven together, so the "recompile JSP" did not automatically
trigger "rebuild JSF structure". This meant that every change required
me to change an id-attribute on a surrounding JSF-tag, which is rather
tedious.
* The "Facelets" technology was developed to solve this problem, and in
the same move goes to XHTML instead of JSP files as the basic format.
This means normal, plain XHTML files, with extra tags in the
JSF-namespaces. Very nice, very simple, very validatable. Save in
editor, reload in browser. Really nice. This also makes <f:verbatim>
superfluous! That is even nicer. It allows for includes, so you can
define snippets in the calling page, which is then used in a template.
* I have found that the Tomahawk library I've used to make JSF 1.1
usable has had the functionality I used added to JSF 1.2, and with XHTML
the tables are much easier to deal with if rowspans or colspans are
needed, as you can just drop to plain html.
Right now we are in the JSP->Facelets migration phase, and it is
primarily a matter of copying the JSP page to XHTML and change the
header from @.... lines to a proper <html... header, and close the open
tags. Also the actions need to return null to stay on the same page as
any string is taken to be the name of the target page instead of having
to specify all navigation in faces-config.xml.
The next step is to migrate from JSF 1.1 to JSF 1.2 to get the Tomahawk
replacements from core JSF and when THAT is done, to migrate from JSF
1.2 up to JSF 2.0. JSF 2.0 should give Ajax tags directly (with inline
partial page updates which we strongly desire to have the data entry
screens update based on the input as it happens) plus the ability to
easily define new components again as XHTML.
My gut feeling so far, is that it is MUCH MUCH nicer to work with, and
that the current work can be almost fully reused directly.
We will then investigate in the Dependency Injection stuff to be able to
brand pages based on resources added at deployment time without changing
the core distribution. That is rather nice too.
midrange.com
