Ok can we all ignore the troll and go back to the original subject...

Like Craig pointed out Rick, I think you should play around with JSF
first and then Shale.
The IBM serie "Cleared FUD about JSF" is a good introduction to. I
think one of the previous poster posted the link.

Shale is decomposed in modules so it not so hard to get a grab on the
functionalities, one type at a time. Actually, it's not very complex
except maybe the Clay plugin wich does require some time to understand
but using it or Facelets instead of JSP is worth the troubles in my
opinion.

Anyway, I have been playing with JSF for sometimes now and here's the
various differences against Struts I've found :

- ActionForm and Action (more Dispatch Action in fact) are replaced by
backing beans.
No more copy between ActionForm and Domain objets or data transfer
objects are necessary.

-The event model is fine-grained instead of coarse-grained. In struts,
you don't have a true event model and the only event is receive a
request and the *listeners* Action, are application wide.

In JSF, the basic event listener are registered on a single component
instead of the complete application. You have two basic different
events (ActionEvent and ValueChangeEvent) and the event listeners all
receive an event object representing the event context. Plus, in JSF
you can register more then one listeners on a component so no need for
Action chaining and the troubles coming along with it. Note that the
action events listeners are not responsible to choose the next view
like the actions are in Struts. It's quite a change but you get used
to it very fast in the end and this way your backing beans (most of
the time, they are the action listeners) are easier to reuse. Overall,
you can understand this quite fast if you are use to program Swing
applications.

- The binding mechanism is way more powerful then Struts one and I
think this is where JSF really shine. In struts, you could only match
form beans properties to forms html tags and it was complex to bind
complex forms. In JSF, you can use EL value bindings or method
bindings expressions. It is really great in my mind and very simple at
the same time, thank to IoC and managed beans.

- Finally, JSF has a component model and so reusing is very easy. The
components hide most of the complexity to the developper (ugly
javascript for exemple). Learning to developp components is what take
time to learn, but you can get started quite fast if you just want to
use it first. At least, there are a lot of exemples available.

- One last thing, since the data and method bindings are specified in
the "jsp/html/whatever technologie you use for view" page and the
navigation is specified globally in the configuration file (not per
action like in Struts), it is quite easy to follow the application
flow. It was something that was annoying me sometimes with Struts, lot
of places to look to find where the executed code is located.

I hope it's help and since I am far from considering me a JSF expert,
anyone can feel free to correct me. And please be tolerant about my
english since I am not a native speaker and it's quite a long post :)

On a side note for people having experience developping custom
components, what annoys me so far in JSF is the model package, in fact
the SelectItem class. There are no model objets for action components
(like you need for a menu or navigation panel) and no universal
components (UISelectItem and UISelectItems) for specifying the model.
You need one for each component and it is quite a pain in the a.. to
code those again and again. Anyway, it always possible to develop your
own model hierarchy and use an adaptor to make SelectItem compatible
with it. As anyone had the same problem so far? If it is the case,
maybe a solution could be part of the future commons-jsf package that
have been discussed in the past. I am working on something around this
problem so I could probably submit it once I'm done.

On 1/7/06, Dakota Jack <[EMAIL PROTECTED]> wrote:
> LOL  I gave him the very same answer that you did, including the same
> citations.  The difference is that I did not gloss over the confusion you
> have systematically engendered by not just owning up to the differences from
> day one.  You don't have to love something to explain it.  Otherwise, who
> would have known about the ugly duckling?
>
> On 1/7/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> >
> >
> >
> > If you are familiar with Core J2EE Patterns terminology, you'll find it
> > easiest to understand JSF and Shale in terms of the View Helper[1]
> > pattern,
> > where the helper items are the JSF component tags and your backing beans,
> > and the Dispatcher View[2] pattern, which combines the Front Controller[3]
> > and View Helper[1] patterns together.  In the Dispatcher View sequence
> > diagram (Figure 7.25) the roles and responsibilities match up like this:
> > Don't expect much help from someone who doesn't seem to care much for
> > either
> > JSF or Shale :-).
> >
> > Mark
> >
> >
> > Craig
> >
> > [1]
> > http://java.sun.com/blueprints/corej2eepatterns/Patterns/ViewHelper.html
> > [2]
> >
> > http://java.sun.com/blueprints/corej2eepatterns/Patterns/DispatcherView.html
> > [3]
> >
> > http://java.sun.com/blueprints/corej2eepatterns/Patterns/FrontController.html
> >
> >
>
>
> --
> "You can lead a horse to water but you cannot make it float on its back."
> ~Dakota Jack~
>
>


--
Alexandre Poitras
Québec, Canada

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to