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
