Sorry to repost this, but I wanted to know if I was the only one facing this
difficulty and if it's the case how to avoid it. Any thougts?

On 1/8/06, Alexandre Poitras <[EMAIL PROTECTED]> wrote:
>
> Just a small correction below :
>
> On 1/8/06, Alexandre Poitras <[EMAIL PROTECTED]> wrote:
> > I am developping a navigation panel like the panel2 from tomahawk (I
> > had to offer some more features) and I like the way you can embedd
> > some navigation items tags (NavigationItem, NavigationItems) inside
> > the navigation tag to specify the different elements of the panel.
> > Since the navigation model elements need some more attributes then
> > SelectItem like an action attribute (supporting MethodBinding of
> > course), you end up developping some custom  models elements just
> > adding some more attributes. I think this part is alright, I don't
> > want to use something generic like DynaFormBean in Struts but I think
> > some base model elements could be standardized like a base class Item
> > and some subclasses like SelectItem and ActionItem (I read somewhere
> > there something similar in Oracle ADF components, maybe I should take
> > a look).
> >
> > The problem I see here is you have to implement for each kind of
> > model, two custom UIxxxItem and UIxxxItems components so you can end
> > up with a lot of redundant UI components. This problem is quite
> > familiar in the OO world and it is usually solved elegantly by the
> > Bridge pattern, where here model elements are the abstraction
> > hierarchy and the UIxxxItem and UIxxxItems are the
> > implementations specific.
>
> I mean the inverse, he UIxxxItem and UIxxxItems are the
> abstraction hierarchy and the model elements the implementation hierarchy.
>
> >So what I would like is to be able to always use the same UI
> > components to specify the model of a parent UI component. What I am
> > doing right now, is whenever a component have a model defined by child
> > elements, it implements a custom interface having a method returning
> > the model class it supports and making sure all model elements have a
> > constructor taking a properties map as an input (in case the element
> > must be built from the UIxxxItem properties). Then I have developped a
> > custom iterator capable of going throught any UI component model
> > implemented by those standard model UI components. Maybe someone have
> > a better design to propose me but it seems to do the trick for the
> > moment. What do you think?
> >
> > Of course with JSP you need to developp a lot of custom tags but I
> > guess not with Clay or facelets :))
> >
> > Here's the link to the Tomahawk panel I was refering to :
> > http://www.irian.at/myfaces/panelnavigation_2.jsp.source
> >
> > On 1/8/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> > > 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
> > >
> > >
> >
> >
> > --
> > Alexandre Poitras
> > Qu�bec, Canada
> >
>
>
> --
> Alexandre Poitras
> Qu�bec, Canada
>



--
Alexandre Poitras
Québec, Canada

Reply via email to