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
