The Form, Action JSP is all very well and good but there are certain limitations to this, for example to be able to plug a non webapp front on the model you have to have a bunch of util classes that manipulate your object model, conversions and such like, so in addition to the web layer struts stuff you've got a hole bunch of files that in JSF you could reduce a lot.
Having the bean (action form) do more than just be a server side representation of a view makes the actual business of making an application cleaner and more straight forward. But there's also the option of using Listeners rather than doing the "doing" stuff in the bean itself.
It also makes sense having validation defined in the view it means not having yet another xml file, yes I know xdoclet can help but its usually 1 step behind (struts 1.2 and servlet 24 cant be done with stable version). OF course having the programming logic in a javaclass makes sense but the choosing of the validation to use and which form element to associate it which makes more sense in the JSP.
Where struts would perhaps be handier would be when you need to stick a weblayer on something thats running already. But then i don't see any huge problems doing this in JSF either.
I just hope the file upload support happens soon, and i can start do all my forms in JSF.
Mark
On 17 Jun 2004, at 22:54, Brian Lee wrote:
I think struts' concept of separating your actions from your data is admirable and should be followed. The concept of your value/transfer objects (basically the form) also having business logic sounds acceptable at first but rapidly becomes a nightmare when you try to use the same value/transfer objects in multiple processes.
I think it's a generally accepted practice that separating data from logic is a "Good Thing"(tm).
BAL
From: "Hookom, Jacob" <[EMAIL PROTECTED]> To: 'Struts Users Mailing List' <[EMAIL PROTECTED]> Subject: RE: Theoretical debate Date: Thu, 17 Jun 2004 14:57:31 -0500
I completely agree with what Crysalis is trying to push, also a framework
called VRaptor (vraptor.org) also pushes the same idea of moving away from
the procedural weight that Struts promotes.
Look at JSF, do you have actions? No, JSF just updates your POJO beans and
calls methods on them. Why have an ActionForm or have to create all of
these Actions that are simply getter/setter adapters? Please don't be too
quick to retort to my supposed anti-struts mindset, but there are other
frameworks out there that allow direct interaction with my business objects
and don't require a heck of a lot of framework specific coding.
---
Example:
To have a multi-page form with JSF, I just create a bean that sits in
Session scope that has a series of getters and setters. JSF will also allow
me to pre-set relationships to other objects at creation time. Then, when
I'm ready to submit the multi-page form, I just put in the jsp
#{myFormBean.submit}. No action mappings, only a managed bean entry.
With Struts, I have to create an ActionForm objects (can't just use a
business object I already have), and then create separate Action objects to
manipulate that ActionForm.
---
-Jacob Hookom
-----Original Message----- From: Frank Zammetti [mailto:[EMAIL PROTECTED] Sent: Thursday, June 17, 2004 2:29 PM To: [EMAIL PROTECTED] Subject: Theoretical debate
Last night I was Googling for something and I stumbled across the Crysalis
framework. I was actualyl intrigued by the underlying premise of it and I
wanted to see what others thought about it.
In a nutshell and in my own words, Crysalis
(http://chrysalis.sourceforge.net/) has the underlying idea that when you
develop in most MVC frameworks, Struts chief among them, you are actually
doing something unnatural and in a way at odds with basic OOP design.
Think about a shopping cart example... If you were going to write that in
straight Java, not for the web or anything, how would you model it? Most
likely you would have a ShoppingCart class with a number of methods in it,
things like addItem(), removeItem(), totalPrice(), etc.
In Struts, although you aren't FORCED to, what you GENERALLY do is create
three different Action classes like addItemAction, removeItemAction and
totalPriceAction, and each is called in response to a form submission.
But isn't it kind of odd that your object model isn't following what you
probably think in your head is the right way, i.e., one class with multiple
related methods? Proper encapsulation and all that jazz, right?
Well, Crysalis does just that. It's controller elements are regular Java
classes with multiple methods. What you wind up with is something that
resembles Remote Procedure Calls instead of numerous servlets as
controllers.
In other words, you would create the ShoppingCart object just as I described
above, with all three methods. Then, when you submit a form, the action is
something along the lines of "ShoppingCart.addItem.cmd". ShoppingCart is
the class to execute, addItem the method and cmd is a suffix to direct the
request, just like extensions in your Struts apps map requests to
ActionServlet.
The elements of the submitted form are treated as the parameters of the
method being called, making it rather elegant.
I haven't gotten into any real detail on Crysalis, but I was interested in
getting other peoples' thoughts on the underlying principal (which I *THINK*
I've stated properly!). It was rather interesting to me because I'd never
reall considered looking at it that way, and certainly it's not the way you
typically approach a Struts-based application. It was also interesting to
me because I've for about four years now been preaching here at work that we
should write our applications as a collection of services that are executed
to form a coherent larger application, which is very much along the lines of
this (so I guess I actually HAVE looked at it this way in a sense, but not
exactly).
Any thoughts?
Frank
_________________________________________________________________
Watch the online reality show Mixed Messages with a friend and enter to win
a trip to NY
http://www.msnmessenger-download.click-url.com/go/onm00200497ave/ direct/01/
--------------------------------------------------------------------- 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]
--------------------------------------------------------------------- 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]
