Just a couple of comments intermixed below.
On 1/7/06, Alexandre Poitras <[EMAIL PROTECTED]> wrote:
>
> 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.
While these are the only two events defined in the standard, it is perfectly
feasible for JSF components to define their own events, and their own event
handlers, using the same basic infrastructure.
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.
I actually wish there wasn't be so much difference here :-(. In the
original vision of Struts, the idea of an ActionForward was very much to
describe an *outcome* ("this is what happened"), not a *destination* ("this
is where to go next"). Unfortunately, most Struts developers don't use
forwards that way -- and you can make exactly the same "mistake" :-) when
using logical outcomes in JSF.
- 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.
The synergy of the managed beans facility is pretty nice ... especially when
you realize you can use bindings on *any* property of *any* component, not
just on the "value" property of an input component.
- 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.
In both environments, the navigation rules are defined globally. The
difference in granularity is how a navigation rule is selected:
* In Struts, it's based solely on the outcome returned by a particular
action
(which can be defined either globally or locally).
* In JSF, it's based (at least for the standard navigation handler; you can
replace
this if you want something different) on three criteria:
- What page am I currently on?
- Which action method was executed?
- What logical outcome was returned by the executed method?
In the JSF case, there are wildcarding capabilities for navigation that also
let you be pretty concise in what you actually have to specify for common
cases.
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 :)
You're doing great ... once you get me past a restaurant menu, my grasp of
French is *really* limited :-).
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.
Could you describe a little more what you think a model object for action
components should do? One of the things I like best about method bindings
is that you do *not* have to conform to a particular interface -- you can
point a submit button (or the node of a tree control, for example) at any
method on any bean class that has the right method sigature. I've seen some
pretty sophisticated menu and tree components that leverage this, without
seeming to feel any pain, so I'd be interested in where you see the
limitations.
Craig
