I think the one thing that hasn't been mentioned. And this is my point of view. The servlet architecture provides the mechanism for the the data flow. Struts utilizes and builds upon it to make it work in a more application-friendly manner. You've got all these roads and highways around, with paths already defined for you on how to get to the store. Why don't you walk there? Or maybe build a vehicle to transport you. I bet you get in the car you bought and drive because it's easier, it makes sense, and you have a solid foundation underneath you (literally and figuratively). Plus you've got features like the a/c and radio -- you may not need them, but they're there to use if you want them. Struts isn't a parallel architecture to the Servlet patterns. Struts builds on that design to make it robust so you don't have to reinvent the wheel. So, yes, Struts "does things in the same way the container does". But, it wraps it in a more friendly control system.



From: "Ranko Bijelonic" <[EMAIL PROTECTED]>
Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>,"Jing Zhou" <[EMAIL PROTECTED]>
Subject: RE: Struts MVC framework similar to that of a servlet container?
Date: Mon, 21 Jul 2003 18:03:31 -0400


>It is my understanding that the servlet spec, jsp spec, and jsf spec are
>regarded
>as the framework of frameworks (a kind of interpretation of mine) Struts
>action mapping is designed in Struts way. If the struts-config.xml is
merged
>into the web.xml, a lot of other frameworks would not happy :-) How do
>you solve such problems from the perspectives of spec leads, when you
>realize Struts way is only one way? I guess they have to investigate a lot
>of
>frameworks before committing one way (a 2 to 4 years effort).

>I presume your TaskAction is a more refined controller than the Struts
>Action. It should understand event types, command name, etc. from the
>http requests in order NOT to overlap the functionality of the Struts
>Action.
>The Struts Actions could recognize the task-config.xml and execute
>configured TaskAction(s) in a workflow manner. In other words, the
>Struts Actions are used to declare what to do, your TaskActions are
>used to specify how to do.

>Does this address enough specific questions you have?

I'm not saying that the container should adopt the way Struts does things,
but that Struts does things in the same way the container does :).  Both are
MVC frameworks wich delegate processing to configured handlers.  Its looks
like its the same thing already.
Ok, so do these extensions that I have built into my more refined controller
warrant rewriting the controller itself, or should I just try to extend
Struts somehow to handle this extra functionality. Take DynaActionForms for
example, its usage is similar to that of a ServletRequest.  I ask for a
parameter/property by name and I get an Object.  It might have some more
functionality, but that could have been added by extending
ServletRequestWrapper just as easily.  I don't know.  It just seems things
could be simpler while maintaining all of the benifits of Struts.

ranko


--------------------------------------------------------------------- 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]

_________________________________________________________________
Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963



--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to