On 12 Oct 2004, at 17:57, Hubert Rabago wrote:
Lots of people more qualified than me to respond to your questions, but I know a little bit about the theory and can give you a preview of what they'll likely say.
On Tue, 12 Oct 2004 11:29:56 -0400, Sean Schofield <[EMAIL PROTECTED]> wrote:I have been doing some reading recently on JSF and I have a few comments and questions.
At first I thought JSF would focus mostly on the "V" in MVC. But after doing some reading on this, it seems like JSF really provides the "M" and "C" as well. Is this accurate?
Its positioned much like struts, the focus is on the controller servlet and there is the option of using Faces JSP if you like , or not. There are example where folk put the model stuff in the controller/backing beans, but this is also true of some struts examples.
Yes. Some even believe the navigation rules of JSF is easier to understand than those of Struts.
I haven't found this, but that could be because I'm used to struts.
It seems possible to combine the view of JSF with the Struts controller (and apparently this is what the integration package is about.) Most of the discussion about combining the two revolves around migration from existing Struts projects to JSF. Other than migration purposes, what is the point in using both?
You could use both if you had no plans of switching fully but would like to take advantage of the UI widgets of JSF.
I like Tiles and plan to continue to use it, but I consider Tiles to be only a small part of Struts. Most of the familiar Struts entities seem to be covered by JSF and I am not sure why it would make sense to keep using Struts if there are features in JSF that are appealing to you. Of course you could use Struts for validation but is it really worth dealing with two frameworks just because you like Struts validation better than JSF validation?
My point in asking these questions is that I am trying decide the direction our current Struts applications should take. I am very happy with Struts but worry that over the long run, the focus will be on JSF and our applications will miss out on some of the developments there.
Whose focus? Struts users miss out on lots of developments outside Struts, but they miss out on Struts progress as well. There are still some active Struts committers, and I suspect a lot of lurkers trying to contribute. There are also lots of Struts 1.3/2.x discussions currently going on, and even Craig himself is still an active participant in those discussions. If you have a Struts-only app, then you're sure to miss out on JSF developments. If you want to use JSF UI components, Craig's struts-faces integration library would help.
Finally, is the ComposableRequestProcessor in struts-chain going to deal with JSF eventually? Will this make it even easier to combine the two?
TIA for you comments and suggestions,
sean
I don't have anything against JSF as a whole, but a lot of times I feel like most switchers are switching just because they feel that other people are switching, too.
I think that faces has some strong advantages over struts, some of which folk may disagree with..
Having backing beans that you can also add processing methods to makes more sense to me.. It makes sense to be to have a save method in the UserBean, not in a separate action.
Some things that jsf brings are good and bad like dataTable, it does more of the work, but some site builders would object to the table being generated rather than being able to tweak bits in. It also only generates html 4 not xhtml, but who really cares as long as its valid / parsable?
The option to save the session on the client means that needing to use LazyLists and such like to store stuff in the request is no longer required. Some folk complain about the huge hidden form property that the sun jsf implementation leaves in the page, but I'd just say that nonesense .NET uses this technique to save state on the client also (not that thats a justification).Of course scoping to session does mean having to clean up after your self, this could be seen as a cost.
I also prefer the validation model, mapping validations in the jsp leaves the site builder to say which validation s/he wants in the jsp. Not tucked away in an xml file or java class.
Out of container Unit testing can be done without struts test case as Backing beans are just plain beans.
You can have void methods for you actions and you're not forced to declare a forward. which is nice for editing type interfaces.
public void saveAction() {
service.save(userBean);
}There are reasons for preferring struts to faces, but also good reasons to prefer faces over struts..
Mark
Hubert
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
