> What do you mean by "inferior if you are interested in performance". Is > the overhead of the dialog/navigation processing pretty high? >
In perspective, vanilla servlet programming is faster than Struts. Isn't it relative to what you *value* in a web framework. Gary > -----Original Message----- > From: Dakota Jack [mailto:[EMAIL PROTECTED] > Sent: Thursday, September 08, 2005 4:19 PM > To: Struts Users Mailing List > Subject: Re: JSF -> Shale transition > > Well, have you considered classic struts? Shale is really meant for > people who are trying to change an application from JSF to Struts, and > not everyone, including myself, think this is a good idea. Shale is not > Struts improved but a transition to something entirely different, and > inferior in my opinion, if you are interested in performance. > > On 9/8/05, Walton, Kaleb (ISS Southfield) <[EMAIL PROTECTED]> wrote: > > We're wanting to go from our home-brewed method of interaction using > > jsps and servlets that are not very consistent in their expression > > (other than the general jsp/servlet specs) to something that defines > > interactions more concretely. Our current frustrations include form > > handling, page transitions, forwarding, etc. > > > > Regards, > > Kaleb > > > > -----Original Message----- > > From: Dakota Jack [mailto:[EMAIL PROTECTED] > > Sent: Thursday, September 08, 2005 12:44 AM > > To: Struts Users Mailing List; [EMAIL PROTECTED] > > Subject: Re: JSF -> Shale transition > > > > Moving from Struts to JSF is moving to a "more defined" framework? > > That is pretty difficult to grasp. Could you explain? > > > > > > > > On 9/6/05, Craig McClanahan <[EMAIL PROTECTED]> wrote: > > > On 9/6/05, Walton, Kaleb (ISS Southfield) <[EMAIL PROTECTED]> wrote: > > > > > > > > Hey all, > > > > > > > > As I had mentioned in a previous post, our team is looking to move > > > > > towards a more well defined web framework. From my limited > > > > experience using Shale (ran the shale-use-cases) I'm not feeling > > > > very confident that we could use it *right away*. > > > > > > > > I wanted to ask for opinions on what would be a gradual step for > > > > us to take towards the Shale framework (once it's stable enough to > > > > > use in a production environment). For example, would JSF + Spring > > > > be a good combo that would make for an easy transition to Shale? > > > > Struts + > > > > > > WebFlow + Spring? Etc.. > > > > > > > > Do the aforementioned framework combinations even matter? Will > > > > Shale > > > > > > just add another layer on top or glue together with what we would > > > > have already developed? Although I've been reading up on Shale > > > > quite > > > > > > a bit, my understanding is still limited so please excuse me if > > > > these questions are easily found through already documented > sources. > > > > > > If they are, please share where they can be found :) > > > > > > > > > > > > The key to choosing a transition approach is what you want to use > > > for the "front controller" part of your architecture durng the > > > interim. If > > > > > you're starting from Struts, a straightforward path would be to use > > > the integration library to start switching your pages to using JSF > > > components instead of Struts HTML tags (without having to modify > > > your actions), followed by a migration of the back-end logic to > > > using JSF's > > > > > front controller and request processing lifecycle. > > > > > > If, on the other hand, you decide to commit to JSF's controller > > > early rather than late, you might as well just use Shale along with > > > it from the beginning. Unlike the way that other frameworks deal > > > with JSF, Shale > > > *assumes* you will be using the JSF controller architecture, and it > > > just adds ease of use around problems you'll face anyway. It doesn't > > > > try to treat JSF as purely a component architecture. > > > > > > Craig McClanahan > > > > > > Regards, > > > > Kaleb --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
