Short version of my experience, last year I created a project with
Seam+Facelets+JSF+EJB3/JPA+jBPM. I was optimist JSF is a standard with 2+ years
old, lot of providers,...
* JSF : I tried to mixed components from several provider, Trinidad, ADT,
MyFaces, Ajax4JSF,... it was a nightweird and time lost (lost of
incompatibility in the configuration, rendering,...)
* JSF : I try to create my own components (and read " Pro JSF and Ajax: Building
Rich Internet Components"), very complex : Request lifec cycle, extensions points,
lot of xml to write and keep sync
* JSF : sometime nothing appends due to exception or reject in the dark zone of the
request life cycle, so don't forget to display "messages" on every page
* JSF : some basic widget (select) always need hack to work
* JSF : create nasty/crapy html, with lot of form, javascript, div : difficult
to debug
* Seam : lot of good idea, need to understand Injection and Outjection, need to
be carefull of scope (request, conversation, session, application) of
In/outjection
* Seam : some features didn't work with third party JSF components
* Seam : required EJB
* Facelets : nice, helping information on failure, templating, tools/facilities
to create simples components
* jBPM : nice GUI to design workflow and pageflow => lot of getter/setter, lot
of xml, not easy to test/mock
* documenation : too many source
After 3 month, I switch to :
* Spring instead of Seam + full EJB3
* hand code instead of jBPM
* session instead conversation scope (spring doesn't support
conversation/continuation natively)
And keep JSF(Facelets+Ajax4JSF+MyFaces), JPA(Hibernate).
About Spring + JSF, you had 2 choice
* every Bean (from spring) could be accessed from a JSF page
* only bean declared into an xml file could be accessed
About html preview :
* facelet allow to use regular html tag with attribute like wicket, but it's an option, and lot of components need to have child component with special tagname and every/lot of component add tag when
it's rendering (runtime) => css from static page template need to be changed.
* facelet like wicket allosw to define fragment, displaying page with fragment
or fragment alone isn't very usefull. (note : I use fragment as general term,
not in the Wicket terminology)
Result : I was pretty happy with the final solution but lot of xml to maintain.
It's quicker to start wth JSF than Wicket, but when to start to customize and
use none basic widget,... welcome to hell (of configuration, documentation,...)
WARN: it's a 2006 experience. I've not used JSF extension/preview from IDE
/david
robert.mcguinness wrote:
...to tell you the truth, it impressed the developers but I didn't get that
feeling from the top brass. I am pretty sure we will move towards
Seam/JSF/Facelets (we have a presentation on that tech next week given by
another developer) since it is "standard".
Has anyone here worked with the Seam tech? All the examples I have seen
(including Facelets) is nothing but tag soup with scriptlets in the page
(albeit small). The configuration for a Seam project seems like a pain and
was also told that the JSF/Seam/Faclets jsp pages can be previewed in a
browser (something I thought was so clever about Wicket html pages...and I
was under the impression that Wicket was the only tech that allowed true
separation of concerns; allowing the web designer to work independenly of
the programmer with no duplication of work between the two). Maybe I'm
blind to Wicket and I'm overlooking Seam and the techs related to it?
I've worked with Freemarker and Struts before and Wicket feels like
"natural" web development. I thought I covered all the great concepts about
Wicket: Ajax, Templating, Inheritance, Reusable Components, OO Concepts…etc…
Bah…just venting. I’m going to have to win the votes of the developers.
I’ll keep everyone posted. Thanks amigos!
- rm3
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
