On Tue, 30 Nov 2004 09:38:17 -0800 (PST), No Galz <[EMAIL PROTECTED]> wrote: > Hii Craig, > > Thanks for your response and clarification. > > I agree that the Struts-Faces library uses JSF URLs > and for make them into use in my application, i need > to change the handling.
Yep. > > But, I have a very dull feeling about using > Struts+Faces together. Moreover things are not going > fine together with different implementations. That's mostly a matter of ironing out bugs, not architectural incompatibility. I just wanted to set expectations correctly. > Just for > curiosity, How Shale is going to make use of JSF in > View?? Isn't it be the same way? Background on "Shale" for those not familiar with the term: http://wiki.apache.org/struts/StrutsShale The use of JSF in Shale, versus the Struts-Faces library approach, is very similar in the view tier (i.e. JSP pages or whatever) -- its the rest of your code that is different. Struts-Faces allows an existing Struts-based app, that has been using the Struts HTML tags, to migrate (one JSP page at a time if desired), to using the more capable and sophisticated JSF components that are becoming available. It accomplishes this task by putting the JSF front controller "in front of" the Struts front controller. That way, JSF handles user interface events (like a tree control node being opened or closed), but passes form submit events on to Struts, to be handled by the traditional Struts request processor. So, all your back end stuff (form beans, actions, and so on) can continue to be used unchanged. Shale, on the other hand, adopts JSF's front controller as its basic architecture, and encourages a "view helper" design pattern for your server side Java code. For application wide things that Struts 1.x would do in the request processing pipeline, you can use servlet filters (which we couldn't in Struts 1.0-1.2, because we wanted to maintain the availability on a servlet 2.2 platform). A JSP page with JSF components in it, then, will look almost the same when using either Struts 1.x + Struts-Faces, or when using Shale. Where Shale helps improve usability, though, is that it reduces the amount of configuration data you need to supply, and combines the form bean, a setup action, and a processing action (the typical Struts pattern for pretty much any transaction) into a single class with very simple method signatures -- so simple, in fact, that it's very easy to unit test them. You can actually see how this all looks in code, because the canonical Struts "mail reader" application has been implemented in each of the two ways. Nightly builds are available at: http://cvs.apache.org/builds/jakarta-struts/nightly/struts-faces/ http://cvs.apache.org/builds/jakarta-struts/nightly/struts-shale/ > > Regards > fargo > Craig
