----- Original Message -----
From: "Ranko Bijelonic" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>; "Jing
Zhou" <[EMAIL PROTECTED]>
Sent: Monday, July 21, 2003 8:31 PM
Subject: RE: Struts MVC framework similar to that of a servlet container?
> >I am getting more clear about your thinking. But saying both (container
and
> >Struts) are MVC frameworks is not accurate in my opinion. Because a
> >container provides you only a 'C' in the MVC pattern; Struts provides you
> >action controller ('C') and form bean ('M') and custom tags in JSP pages
> >('V').
>
> The custom tags (especially now with JSTL) can be used with the container
> 'C' also. So now we are left with 'M'.
There are no counterparts of the Struts html tag library in JSTL. So we
can't
reach the conclusion so quickly. JSF is supposed to offer that. But it is
not born yet.
> I don't consider form beans to be the model, or the whole of the model.
> However its much closer like that.
>
You are right. That is the problem of the current form bean model in
Struts 1.1. However, one of benefits of staying with Struts is that you have
more choices than you pave your own roads. For example, we have
form bean model that is qualified as level one model (12 standard
types are supported, not just string). The Struts users may not want to
use it today, but they have the CHOICES. Someday for some reason,
some of them may use it.
If someone paves his own roads, the choices are up in the air ... That
is my point. Of course, for a particular individual or project, the choice
might not be that important.
Jing
> -----Original Message-----
> From: Jing Zhou [mailto:[EMAIL PROTECTED]
> Sent: Monday, July 21, 2003 7:14 PM
> To: Ranko Bijelonic; Struts Users Mailing List
> Subject: Re: Struts MVC framework similar to that of a servlet
> container?
>
>
>
> ----- Original Message -----
> From: "Ranko Bijelonic" <[EMAIL PROTECTED]>
> To: "Struts Users Mailing List" <[EMAIL PROTECTED]>; "Jing
> Zhou" <[EMAIL PROTECTED]>
> Sent: Monday, July 21, 2003 5:03 PM
> Subject: RE: Struts MVC framework similar to that of a servlet container?
>
>
> > >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.
>
> I am getting more clear about your thinking. But saying both (container
and
> Struts) are MVC frameworks is not accurate in my opinion. Because a
> container provides you only a 'C' in the MVC pattern; Struts provides you
> action controller ('C') and form bean ('M') and custom tags in JSP pages
> ('V').
>
> In addition, Struts partition one web application into application modules
> for higher scalability of engineering processes. You could not achieve
this
> using only web.xml.
>
> > 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.
>
> The dyna form is *similar* to a ServletRequest. But it could be nested
> inside other form beans in addition to its configurable properties. A
simple
> ServletRequestWrapper would not make the *whole* job disappeared if you
> do not use the common's beanutils.
>
> But it did invoke scaring thoughts at early time when people thought the
> benefits of dyna forms are marginal to a ServletRequest. But technologies
> advance, much powerful form bean model has been designed ...
>
> >
> > ranko
> >
>
> Jing
>
> >
> > ---------------------------------------------------------------------
> > 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]
