Ranko, you could just buy Dynamo or WebSphere or WebLogic - that'll give you all you need, tightly integrated :). Where are you from BTW? Serbia, Croatia??
Martin -- Monday, July 21, 2003, 3:26:06 PM, you wrote: RB> That's what I tought too until i read that discussion on sun forums. man I RB> wish I did not :). RB> Now it seems to me that it duplicates more than it extends. Yes, there are RB> some ease of programing additions, but i'd prefer them without all the RB> duplicted stuff and integrated with the servlet controller/handler system. RB> with struts, one tends of tune out the servlet spec and use the Struts RB> facilities for everyting even though they might overlap and look the same as RB> the standard ones. And it grows: we have declerative exception handling in RB> web.xml, but we added a little better one to struts-config.xml. we have a RB> generic form (its the request), but we added i guess a more functional one RB> (DynaActionForm) usage of which is the same in most cases. one was able to RB> define a JDBC data source in a container and then use JNDI to find it, but RB> now you can define it in struts-config.xml. When are distributed objects RB> comming? :). just kidding :) RB> -----Original Message----- RB> From: Adam Levine [mailto:[EMAIL PROTECTED] RB> Sent: Monday, July 21, 2003 6:12 PM RB> To: [EMAIL PROTECTED] RB> Subject: RE: Struts MVC framework similar to that of a servlet RB> container? RB> I think the one thing that hasn't been mentioned. And this is my point of RB> view. The servlet architecture provides the mechanism for the the data RB> flow. Struts utilizes and builds upon it to make it work in a more RB> application-friendly manner. You've got all these roads and highways RB> around, with paths already defined for you on how to get to the store. Why RB> don't you walk there? Or maybe build a vehicle to transport you. I bet you RB> get in the car you bought and drive because it's easier, it makes sense, and RB> you have a solid foundation underneath you (literally and figuratively). RB> Plus you've got features like the a/c and radio -- you may not need them, RB> but they're there to use if you want them. Struts isn't a parallel RB> architecture to the Servlet patterns. Struts builds on that design to make RB> it robust so you don't have to reinvent the wheel. So, yes, Struts "does RB> things in the same way the container does". But, it wraps it in a more RB> friendly control system. RB> From: "Ranko Bijelonic" <[EMAIL PROTECTED]> RB> Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]> RB> To: "Struts Users Mailing List" <[EMAIL PROTECTED]>,"Jing Zhou" RB> <[EMAIL PROTECTED]> RB> Subject: RE: Struts MVC framework similar to that of a servlet container? RB> Date: Mon, 21 Jul 2003 18:03:31 -0400 RB> >It is my understanding that the servlet spec, jsp spec, and jsf spec are RB> >regarded RB> >as the framework of frameworks (a kind of interpretation of mine) Struts RB> >action mapping is designed in Struts way. If the struts-config.xml is RB> merged RB> >into the web.xml, a lot of other frameworks would not happy :-) How do RB> >you solve such problems from the perspectives of spec leads, when you RB> >realize Struts way is only one way? I guess they have to investigate a lot RB> >of RB> >frameworks before committing one way (a 2 to 4 years effort). RB> >I presume your TaskAction is a more refined controller than the Struts RB> >Action. It should understand event types, command name, etc. from the RB> >http requests in order NOT to overlap the functionality of the Struts RB> >Action. RB> >The Struts Actions could recognize the task-config.xml and execute RB> >configured TaskAction(s) in a workflow manner. In other words, the RB> >Struts Actions are used to declare what to do, your TaskActions are RB> >used to specify how to do. RB> >Does this address enough specific questions you have? RB> I'm not saying that the container should adopt the way Struts does things, RB> but that Struts does things in the same way the container does :). Both are RB> MVC frameworks wich delegate processing to configured handlers. Its looks RB> like its the same thing already. RB> Ok, so do these extensions that I have built into my more refined controller RB> warrant rewriting the controller itself, or should I just try to extend RB> Struts somehow to handle this extra functionality. Take DynaActionForms for RB> example, its usage is similar to that of a ServletRequest. I ask for a RB> parameter/property by name and I get an Object. It might have some more RB> functionality, but that could have been added by extending RB> ServletRequestWrapper just as easily. I don't know. It just seems things RB> could be simpler while maintaining all of the benifits of Struts. RB> ranko RB> --------------------------------------------------------------------- RB> To unsubscribe, e-mail: [EMAIL PROTECTED] RB> For additional commands, e-mail: [EMAIL PROTECTED] RB> --------------------------------------------------------------------- RB> To unsubscribe, e-mail: [EMAIL PROTECTED] RB> For additional commands, e-mail: [EMAIL PROTECTED] RB> _________________________________________________________________ RB> Protect your PC - get McAfee.com VirusScan Online RB> http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 RB> --------------------------------------------------------------------- RB> To unsubscribe, e-mail: [EMAIL PROTECTED] RB> For additional commands, e-mail: [EMAIL PROTECTED] RB> --------------------------------------------------------------------- RB> To unsubscribe, e-mail: [EMAIL PROTECTED] RB> For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
