struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alen Ribic" <al...@mweb.co.za>
Subject Re: Struts MVC framework similar to that of a servlet container?
Date Tue, 22 Jul 2003 06:57:45 GMT
I lived in Serbia long, long time ago. (Novi Sad) ;)
.2c
--Alen


----- Original Message -----
From: "Ranko Bijelonic" <rbijelonic@yahoo.com>
To: "Struts Users Mailing List" <struts-user@jakarta.apache.org>; "Martin
Naskovski" <mnaskovs@san.rr.com>
Sent: Tuesday, July 22, 2003 3:38 AM
Subject: RE: Struts MVC framework similar to that of a servlet container?


> I'll wait for Struts 3.0.  It should be J2EE compliant by then :) hehe.
> Serbia.
>
> -----Original Message-----
> From: Martin Naskovski [mailto:mnaskovs@san.rr.com]
> Sent: Monday, July 21, 2003 8:29 PM
> To: Ranko Bijelonic
> Cc: Struts Users Mailing List
> Subject: Re: Struts MVC framework similar to that of a servlet
> container?
>
>
> 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:adam_l_levine@hotmail.com]
> RB> Sent: Monday, July 21, 2003 6:12 PM
> RB> To: struts-user@jakarta.apache.org
> 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" <rbijelonic@yahoo.com>
> RB> Reply-To: "Struts Users Mailing List" <struts-user@jakarta.apache.org>
> RB> To: "Struts Users Mailing List" <struts-user@jakarta.apache.org>,"Jing
> Zhou"
> RB> <jing@netspread.com>
> 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: struts-user-unsubscribe@jakarta.apache.org
> RB> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>
> RB> ---------------------------------------------------------------------
> RB> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> RB> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
> 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: struts-user-unsubscribe@jakarta.apache.org
> RB> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>
> RB> ---------------------------------------------------------------------
> RB> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> RB> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org


Mime
View raw message