You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Ted Husted <hu...@apache.org> on 2002/12/12 04:59:28 UTC
Why are people up on Struts
>>Struts is not very powerful. There's no action chaining; all of
the models are one layer deep. Talking with a Struts user, I was
reminded of the ability of an action to forward to another action,
and it's easier than I thought. Silly rabbit. :)
'nuff said.
Although, I'm among those who recommend against action-chaining,
since it implies that there is too much business logic in the
Action class. (The "chaining" should happen on the business tier.)
But, there's nothing to prevent it (if you are wearing your
bullet-proof shoes).
>>Struts is bound to the web. You can't use it outside of the
context of a servlet engine. Model-View-Controller is a very
generic paradigm; don't you think implementations should follow
the paradigm?
Struts is intended as a Java Model 2/MVC framework, and it is
bound to Java servlets. It is not really bound to HttpServlet, but
that's what nearly everyone uses it for.
For more about using Swing and Struts together, see
<http://javaboutique.internet.com/tutorials/Swing/>
It's my feeling that many of the Struts elements can be pushed up
a notch. There is definately a need for a generic MVC framework
that can then interact with Struts on the web tier and something
else on some other tier.
>>Struts has poor configuration. Struts is bound to the web, so
you'd think that Least Astonishment would allow you to use web
semantics, but the config file does things to hide that from you.
As mentioned, the underlying design is not bound to the web, which
is why the configuration semantics are generic. In general, Struts
helps to hide web semantics by transferring parameters to JavaBean
properties. It's possible to write many significant web
applications without delving into "web semantics".
>>Struts tries to do everything for you: UI, logic, templating,
MVC. In other words, it's not a toolkit, it's a platform. An
example of this is Struts' JDBC pool: it's very developer-
friendly, but not deployer-friendly. The deployer, if he's using a
different database, is faced with changing the deployed
configuration. BZZZT. Not good J2EE, guys.
The opposite is really true. Struts tries to NOT do everything for
you. Struts draws on other components for its UI (JSPs, Velocity,
XLST), and is completely model neutral. If some standard someplace
is ready to do the job, then Struts is more than willing to let it
=:0)
The Struts connection pool is a good example. If you do decide to
use it, any component based on the standard DataSource interface
can be used. One possible connection pool is bundled as an example
(currently the Commons DBCP), but, like the bundled taglibs,
that's just one example of how to plug standard technologies into
Struts.
In fact, if you are using the Struts Generic Datasource, you can
actually change connection pools or databases without changing
your deployment. You access the datasource through a logical name,
any datasource can be on the other side of that name.
Meanwhile, because Struts is so popular, a great many developers
have made their own contributions available. This can make Struts
seem like a platform. But, like Eclipse, Struts is a core
framework into which you can plug your own stuff.
In Struts 1.1, we added two of the most popular contributions to
the core distribution: Tiles and the Validator. But not because we
went out and developed them, but because so many people were
already using them. Like the taglibs, they also serve as a very
good example of how to integrate your own components with Struts.
>>Struts dictates the view to you: you pretty much have to use JSP
in order to use Struts. I suppose the mindset is that if you're
going to be bound to the web, why not bind yourself as much as you
can? Author's Note: it turns out that this bullet point is
incorrect. As the, erm, home page for Struts indicates, you can
use many presentation systems for Struts views, which makes
perfect sense; Your Humble Author was working off of the emphasis
on taglibs and a slightly outdated view. This is why public
discussions are better than private discussions. :)
'nuff said.
But, back to your initial theme: Why do some people on #java
disrespect Struts evangelists?
Given the large community behind Struts, we do have our share of
zealots. And, I agree that people who believe Struts is "42" are
not being realistic.
Is Struts the best of all possible Model 2 frameworks? Certainly
not! Is Barracuda, or Maverick, or Tapestry, or WebWorks, the best
of all possible MVC frameworks. Probably not. (At least not yet.)
Personally, I believe the best MVC framework has yet to be
written.
To most of us, Struts Committers included, Struts is just a means
to an end. Some of us needed a Model 2 framework, so we (mostly
Craig) wrote one. We continued to improve it as we came across new
ideas. But along the way, we've all seen lots of places where we
could-a, should-a -- if we only knew then, what we know now. And
in Struts 2.x, we hope to put that experience to task and write a
framework that will serve our needs even better than any framework
does today.
A big reason Struts has gained momentum is because it draws on
standard technologies that most developers already know how to
use. In Struts 2.x, we may be able to draw more heavily on the
other defacto standard framework technologies and assemble a true
"best-of-breed" solution.
(The other big reason being Struts, like other good Apache-Jakarta
products, emphasizes community over technology. But, that's kinda
"standards" thing too.)
What we need to think about is what we *really* want an
application framework to look like (as the Barracuda team did),
and then plot a course.
I've a few notes on subject here:
http://husted.com/struts/usecases.html
Though, these are still just Sunday morning musings.
Buy, if you'd like to shape the future of the world's most popular
web application framework, stick around and pitch in.
The best is yet to come =:0)
-Ted.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Action chaining: (was - Re: Why are people up on Struts)
Posted by Erik Hatcher <ja...@ehatchersolutions.com>.
V. Cekvenich wrote:
>
> /do/action?dispatch=delete or anything else.
Yeah, I get that for the case where I want to delete and return to the
list view. But how about a case where have some other page that wants a
delete link to delete an item, but then return back to that same page?
You'd have to copy your delete code to a new action whereas I'd simply
create a new action mapping and reuse an existing single-purpose action.
The action code you posted earlier is *not* single-purpose in my view,
its deleting and regenerating the list.
Or am I missing some piece of your design?
Erik
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Action chaining: (was - Re: Why are people up on Struts)
Posted by "V. Cekvenich" <vc...@basebeans.com>.
/do/action?dispatch=delete or anything else.
Erik Hatcher wrote:
> Thats too tightly coupled for my tastes though. What if I want to put a
> delete hyperlink on some other page and have it forward somewhere else?
>
> In your example I don't think you'd have that capability. In my
> chaining methodology I'd create a different action mapping pointing to
> the same Java Action and just have a different forward.
>
> How would you accomplish this same thing?
>
> Erik (with a "k")
>
>
> V. Cekvenich wrote:
>
>> Eric, my actions do CRUD + default.
>> So I have onSave(), onDelete, onDisplay, onDefault, etc. on set of
>> actions that relate to he JSP.
>>
>> So in onDelete(EventObj event) I do this
>> {
>> ..
>> bean.delete();
>> onDisplay(event); // on display does bean.find()
>>
>> }
>>
>> hth, .V
>>
>> Erik Hatcher wrote:
>>
>>> Ted Husted wrote:
>>>
>>>>>> Struts is not very powerful. There's no action chaining; all of
>>>>>
>>>>>
>>>>>
>>>>>
>>>> the models are one layer deep. Talking with a Struts user, I was
>>>> reminded of the ability of an action to forward to another action,
>>>> and it's easier than I thought. Silly rabbit. :)
>>>> 'nuff said.
>>>> Although, I'm among those who recommend against action-chaining,
>>>> since it implies that there is too much business logic in the Action
>>>> class. (The "chaining" should happen on the business tier.) But,
>>>> there's nothing to prevent it (if you are wearing your bullet-proof
>>>> shoes).
>>>
>>>
>>>
>>>
>>> I'm one of those that find action-chaining very helpful. Here's an
>>> example of how/why I use it (all JSP's are under WEB-INF)
>>>
>>> - A list view of all items
>>> - A delete link by each of the items
>>> - User clicks to delete an item
>>> - DeleteAction deletes the item and wants to forward back to
>>> the list view
>>> - An action is needed to generate the list view dynamically
>>>
>>> I simply chain the "success" forward of the "/delete" mapping to
>>> "/view.do".
>>>
>>> I've yet to see a solution that doesn't blur the delete step with the
>>> generate list view step - and this forces actions to be tied to how
>>> its used in the GUI, which to me goes against what Struts is all
>>> about. Creating tiny actions that only do one single thing and then
>>> glue them together in struts-config is something I find very helpful.
>>>
>>> Is there a cleaner way to do this without action chaining?
>>>
>>> Erik
>>
>>
>>
>>
>>
>>
>> --
>> To unsubscribe, e-mail:
>> <ma...@jakarta.apache.org>
>> For additional commands, e-mail:
>> <ma...@jakarta.apache.org>
>>
>>
>>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Action chaining: (was - Re: Why are people up on Struts)
Posted by Erik Hatcher <ja...@ehatchersolutions.com>.
Thats too tightly coupled for my tastes though. What if I want to put a
delete hyperlink on some other page and have it forward somewhere else?
In your example I don't think you'd have that capability. In my
chaining methodology I'd create a different action mapping pointing to
the same Java Action and just have a different forward.
How would you accomplish this same thing?
Erik (with a "k")
V. Cekvenich wrote:
> Eric, my actions do CRUD + default.
> So I have onSave(), onDelete, onDisplay, onDefault, etc. on set of
> actions that relate to he JSP.
>
> So in onDelete(EventObj event) I do this
> {
> ..
> bean.delete();
> onDisplay(event); // on display does bean.find()
>
> }
>
> hth, .V
>
> Erik Hatcher wrote:
>
>> Ted Husted wrote:
>>
>>>>> Struts is not very powerful. There's no action chaining; all of
>>>>
>>>>
>>>>
>>> the models are one layer deep. Talking with a Struts user, I was
>>> reminded of the ability of an action to forward to another action,
>>> and it's easier than I thought. Silly rabbit. :)
>>> 'nuff said.
>>> Although, I'm among those who recommend against action-chaining,
>>> since it implies that there is too much business logic in the Action
>>> class. (The "chaining" should happen on the business tier.) But,
>>> there's nothing to prevent it (if you are wearing your bullet-proof
>>> shoes).
>>
>>
>>
>> I'm one of those that find action-chaining very helpful. Here's an
>> example of how/why I use it (all JSP's are under WEB-INF)
>>
>> - A list view of all items
>> - A delete link by each of the items
>> - User clicks to delete an item
>> - DeleteAction deletes the item and wants to forward back to
>> the list view
>> - An action is needed to generate the list view dynamically
>>
>> I simply chain the "success" forward of the "/delete" mapping to
>> "/view.do".
>>
>> I've yet to see a solution that doesn't blur the delete step with the
>> generate list view step - and this forces actions to be tied to how
>> its used in the GUI, which to me goes against what Struts is all
>> about. Creating tiny actions that only do one single thing and then
>> glue them together in struts-config is something I find very helpful.
>>
>> Is there a cleaner way to do this without action chaining?
>>
>> Erik
>
>
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Action chaining: (was - Re: Why are people up on Struts)
Posted by "V. Cekvenich" <vc...@basebeans.com>.
Eric, my actions do CRUD + default.
So I have onSave(), onDelete, onDisplay, onDefault, etc. on set of
actions that relate to he JSP.
So in onDelete(EventObj event) I do this
{
..
bean.delete();
onDisplay(event); // on display does bean.find()
}
hth, .V
Erik Hatcher wrote:
> Ted Husted wrote:
>
>>>> Struts is not very powerful. There's no action chaining; all of
>>>
>>>
>> the models are one layer deep. Talking with a Struts user, I was
>> reminded of the ability of an action to forward to another action, and
>> it's easier than I thought. Silly rabbit. :)
>> 'nuff said.
>> Although, I'm among those who recommend against action-chaining, since
>> it implies that there is too much business logic in the Action class.
>> (The "chaining" should happen on the business tier.) But, there's
>> nothing to prevent it (if you are wearing your bullet-proof shoes).
>
>
> I'm one of those that find action-chaining very helpful. Here's an
> example of how/why I use it (all JSP's are under WEB-INF)
>
> - A list view of all items
> - A delete link by each of the items
> - User clicks to delete an item
> - DeleteAction deletes the item and wants to forward back to
> the list view
> - An action is needed to generate the list view dynamically
>
> I simply chain the "success" forward of the "/delete" mapping to
> "/view.do".
>
> I've yet to see a solution that doesn't blur the delete step with the
> generate list view step - and this forces actions to be tied to how its
> used in the GUI, which to me goes against what Struts is all about.
> Creating tiny actions that only do one single thing and then glue them
> together in struts-config is something I find very helpful.
>
> Is there a cleaner way to do this without action chaining?
>
> Erik
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Action chaining
Posted by Ted Husted <hu...@apache.org>.
Well, there's Action chaining, and there's action chaining. It's a
perfectly valid idea for an ActionMapping to select where control
should go next, as Erik is doing. It's fundamental to the
architechtural, and instrumental to how ActionForm validation
works.
So, if we're talking about one ActionMapping forwarding (or
redirecting) to another ActionMapping, then sure. Everything is
above board, and you can follow the bouncing ball through the
Struts Config and see what's happening.
But, then there's Action chaining. Here, people have an Action
class create an ActionForward on the fly, jam in some parameters,
and toss it back to the controller. This is where Action classes
start binding to Action classes, and the mudslide begins.
It's my feeling that if Action classes start creating query
strings and need to be coded in terms of what they need to send to
the "next" Action, then you're starting to use Action classes to
implement a business facade. Action classes should be clients of
the facade, not the facade itself.
In the current example, using an ActionMapping to call a
DeleteAction and have it route back to some list afterwards seems
fine to me. So, long as the DeleteAction doesn't know or care if
its going back to a particular list or a given form. IMHO, an
Action class should just return a simple semantic like "success",
"failure", "cancel", and so forth, and let the ActionMapping
decide how to handle the given gesture.
And following Laird's example, an application could also include a
workflow engine that would return a semantic to go get the
whatchacallit. But the ActionMappings would hook up the semantic
with the actual URI. The real "presentation logic" is that there's
a JSP stored at /WEB-INF/pages/whatchacallit. On top of that,
there's application/workflow logic that might say the semantic
"whatchamcallit" should display the form that collects the
whatchallit property.
Where things get messy is that sometimes people come up with a
multi-step server-side workflow, where they want to, say, copy and
delete (or move) a record, and then return to a list. So you got
the copy action looking at some flag that says "do delete next",
and so it sets something in the request or action form, and
forwards on to delete, which then looks at something that tells it
to forward on to a list.
In this case, we're starting to do a Rube Goldberg shuffle around
Robin Hood's barn. There should just be a move action that calls
both copy and delete through the business facade -- being the
exact same methods an independant copy or delete Action would
call. If there is more than a line or two of code involved in an
atomic process like delete, then the Action classes are working
too hard.
IMHO, Action classes should not be considered atomic. Most often,
there should be a 1:1 correlation between an Action class and your
business facade. The business facade is your application's
internal API. It defines what the application can do, what it
needs to do it, and what it returns when something is done. The
Action classes interact with the business facade by allowing
access to the facade from the web tier. Other tiers could also
interact with the same facade from other platforms.
So, given the trivial move example, the Action should not even
have to call copy and delete. There should be move method on the
facade, and the facade should be the one calling copy and delete.
Behind the facade are the atomic operations, like delete or copy.
The facade then does any chaining or nesting between atomic
operations. The atomic operations may be implemented using JDBC or
EJB or CORBA or Lucene or a web service or whatever you like. But
the actions don't need to know that, because they only talk to the
facade.
<preaching-to-the-choir>Of course, setting up a facade is some
extra work, and so not everyone does it. Just like setting up an
interface before defining a base class is some extra work. Using
actions for your facade works, just like using base classes
instead of interfaces works. In either case, you are trading a
layer of indirection for reusability.</preaching-to-the-choir>
But, now we may be getting into the stuff of the user list =:0)
-Ted.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Action chaining: (was - Re: Why are people up on Struts)
Posted by Martin Cooper <ma...@apache.org>.
This has been a fascinating thread to catch up on! ;-) I'm more than a
little surprised, though, that everyone's still "in the box" on a solution
to Erik's problem.
I have exactly the same scenario that Erik does - basically, you have some
code that deals with the incoming request, and some code that deals with
preparing to present the next page, and you want to decouple those. One
solution, which is where this thread started, is action chaining, but we
know there are issues with that.
A much cleaner solution involves just a little thinking outside the box.
Who said that the request handling and the presentation handling code had
to be in Action classes? Nobody. So don't do that. ;-)
The solution I am currently using is based on the idea of "request
handlers" and "display handlers". These handlers are *not* Action classes
- they are entirely independent of Actions. A single HandlerAction class
knows how to invoke a configured request handler first, and then invoke
the appropriate display handler after that. Everything is configured
externally, in XML.
Using Erik's example, this lets me put the code for the delete step and
the generate list view step in different classes, and externally configure
the connection between the two, without using action chaining and without
using action forwards. In my application, this is a strict requirement,
because other people (not necessarily employed by my company) must be able
to reconfigure the application itself without modifying Java code, and
it's not OK to require them to understand the ins and outs of action
chaining.
Once any remaining wrinkles are ironed out, I hope to be able to persuade
my employer that contributing this code to Struts is the right thing to
do, and therefore make this extension available in contrib (or perhaps
even core, given how many people seem to run into these issues).
--
Martin Cooper
On Thu, 12 Dec 2002, Erik Hatcher wrote:
> Ted Husted wrote:
> >>>Struts is not very powerful. There's no action chaining; all of
> >>
> > the models are one layer deep. Talking with a Struts user, I was
> > reminded of the ability of an action to forward to another action,
> > and it's easier than I thought. Silly rabbit. :)
> >
> > 'nuff said.
> >
> > Although, I'm among those who recommend against action-chaining,
> > since it implies that there is too much business logic in the
> > Action class. (The "chaining" should happen on the business tier.)
> > But, there's nothing to prevent it (if you are wearing your
> > bullet-proof shoes).
>
> I'm one of those that find action-chaining very helpful. Here's an
> example of how/why I use it (all JSP's are under WEB-INF)
>
> - A list view of all items
> - A delete link by each of the items
> - User clicks to delete an item
> - DeleteAction deletes the item and wants to forward back to
> the list view
> - An action is needed to generate the list view dynamically
>
> I simply chain the "success" forward of the "/delete" mapping to "/view.do".
>
> I've yet to see a solution that doesn't blur the delete step with the
> generate list view step - and this forces actions to be tied to how its
> used in the GUI, which to me goes against what Struts is all about.
> Creating tiny actions that only do one single thing and then glue them
> together in struts-config is something I find very helpful.
>
> Is there a cleaner way to do this without action chaining?
>
> Erik
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Action chaining: (was - Re: Why are people up on Struts)
Posted by Erik Hatcher <ja...@ehatchersolutions.com>.
Ted Husted wrote:
> IMHO, the Actions shouldn't be doing anything except calling
> business methods. So, instead of chaining to a DeleteAction, *any*
> action should be able call the delete method of the business
> facade.
My actions *only* call business methods. I'm chaining "away" from the
DeleteAction, not to it. DeleteAction chains to the view action in the
simple example.
And yes, any action could call the delete method sure. Nothing
restricting that from happening in what I'm saying.
> Ideally, any chaining or nesting should take place behind a
> business facade. When someone starts nesting or chaining actions,
> it's an indicate that the actions are being used to implement the
> facade.
That all sounds fine and well, but lets talk specifics :)
*How* do you do it specifically? Especially given my last post to Vic
where I want a delete action to be independently available to be used
from any page allowing it to forward to other places if desired which
may not be a view.
> Now, a lot of people do use actions as a facade. I wrote my first
> significant Struts application this way. I got it out the door
> very quickly and it performs very well. But, now, in maintenance
> mode, I regret that expediency, since it is hard to test and
> always feels fragile to me.
I'm not sure I see what is fragile about how I go about things. My
actions are very lightweight and single purpose, and extremely reusable.
Erik
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Action chaining: (was - Re: Why are people up on Struts)
Posted by Ted Husted <hu...@apache.org>.
12/12/2002 6:30:18 AM, Erik Hatcher <jakarta-
struts@ehatchersolutions.com> wrote:
>I've yet to see a solution that doesn't blur the delete step with
the
>generate list view step - and this forces actions to be tied to
how its
>used in the GUI, which to me goes against what Struts is all
about.
>Creating tiny actions that only do one single thing and then glue
them
>together in struts-config is something I find very helpful.
>
>Is there a cleaner way to do this without action chaining?
IMHO, the Actions shouldn't be doing anything except calling
business methods. So, instead of chaining to a DeleteAction, *any*
action should be able call the delete method of the business
facade.
Ideally, any chaining or nesting should take place behind a
business facade. When someone starts nesting or chaining actions,
it's an indicate that the actions are being used to implement the
facade.
Now, a lot of people do use actions as a facade. I wrote my first
significant Struts application this way. I got it out the door
very quickly and it performs very well. But, now, in maintenance
mode, I regret that expediency, since it is hard to test and
always feels fragile to me.
-Ted.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Action chaining: (was - Re: Why are people up on Struts)
Posted by Erik Hatcher <ja...@ehatchersolutions.com>.
Ted Husted wrote:
>>>Struts is not very powerful. There's no action chaining; all of
>>
> the models are one layer deep. Talking with a Struts user, I was
> reminded of the ability of an action to forward to another action,
> and it's easier than I thought. Silly rabbit. :)
>
> 'nuff said.
>
> Although, I'm among those who recommend against action-chaining,
> since it implies that there is too much business logic in the
> Action class. (The "chaining" should happen on the business tier.)
> But, there's nothing to prevent it (if you are wearing your
> bullet-proof shoes).
I'm one of those that find action-chaining very helpful. Here's an
example of how/why I use it (all JSP's are under WEB-INF)
- A list view of all items
- A delete link by each of the items
- User clicks to delete an item
- DeleteAction deletes the item and wants to forward back to
the list view
- An action is needed to generate the list view dynamically
I simply chain the "success" forward of the "/delete" mapping to "/view.do".
I've yet to see a solution that doesn't blur the delete step with the
generate list view step - and this forces actions to be tied to how its
used in the GUI, which to me goes against what Struts is all about.
Creating tiny actions that only do one single thing and then glue them
together in struts-config is something I find very helpful.
Is there a cleaner way to do this without action chaining?
Erik
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>