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. 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 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
