You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by atta-ur rehman <at...@gmail.com> on 2005/04/01 06:40:41 UTC
Which MVC Layer ActionForm Belongs To?
Dea all,
I'm sure I've seen this topic before! Just can't remember where and
google won't help either! Can anybody please explain which MVC layer
form belongs?
TIA.
ATTA
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Which MVC Layer ActionForm Belongs To?
Posted by atta-ur rehman <at...@gmail.com>.
Frank,
I like your M+V+C channeling examples!
Thanks.
ATTA
On Apr 1, 2005 5:53 AM, Frank W. Zammetti <fz...@omnytex.com> wrote:
> "...we might as well be discussing how many angels can dance on the head
> of a pin"
>
> 639. 704 if they all go to LA Weight Loss for 3 months. But either way
> that assumes they haven't been drinking, otherwise they won't be able to
> keep their balance long enough to count. I believe this research was
> done at AMD development labs in coming up with the Athlon 64. But I
> couldn't find a reference online.
>
> (Ahem. There goes my standup career.)
>
> About the ActionForms... I don't personally consider them part of either
> layer. Tangentially, the same goes for Value Objects. They straddle
> the line between two layers in my mind. They are the channel through
> which the view communicates with the control layer, and Value Objects
> are the channel through which the control layer communicates with the
> model. Hence, I don't consider them part of either layer. Perhaps we
> should stop calling it MVC and instead call it M+V+C, with the + signs
> indicating those channels. :)
>
> Perhaps that's a politician's answer, avoid giving a real answer to a
> sticky question :) but I actually feel like that fits the evidence, so
> to speak. Depends on what the definition of "is" is I guess :)
>
> Frank
>
> Ted Husted wrote:
> > Well, you know, an ActionForm is what it is. :)
> >
> > On this list, most people will tell you it belongs to the View.
> >
> > Other frameworks with similar architectural members call gizmos like
> > ActionForms the "Model". Why? Because in classic MVC, the View
> > subscribes to the Model, most often as an Observer. In a conventional
> > Model 2 application, the View acquires data from the servlet contexts
> > --- meaning the servlet contexts become the M in MVC. The JSP Tags
> > "observe" critters like the ActionForm in the servlet contexts, hence,
> > the argument would go, it's part of the Model. Snagging data from the
> > contexts is not quite the Observer pattern, but it does have the same
> > effect.
> >
> > Of course, since most, or all, of that data actually comes from a
> > database, a lot of people tend to think of the database as the Model.
> > And, in the big picture, the database usually is the one-true Model.
> > But from the narrow perspective of Model-2 MVC, the JavaBeans we stuff
> > into the servlet contexts do become, for all intents and purposes, the
> > Model.
> >
> > One way to think of it is that our Views aren't designed to gaze upon
> > the Model directly. So, the Controller creates a specialized form of
> > the Model and places that chunk in the servlet context, where the
> > Views can see it. From the View's perspective, the dynamic data in the
> > servlet contexts is the Model. (Even though we know it's just a
> > runtime snapshot of one sliver of the most-high database Model.)
> >
> > As to ActionForms in particular, personally, I consider everything in
> > the Struts core (Action package) to be part of our Controller layer.
> > The taglibs are our View, but the rest, including the ActionForm, is
> > part of the Controller. The Controller simply shares the ActionForm
> > with the View by putting it the Servlet context (so it becomes part of
> > the Model as observed by the View).
> >
> > Of course, in the end, it doesn't really matter. The ActionForm is
> > what the ActionForm is. The one thing it is not, is a business object.
> > The Controller creates it from the request, and it bounces around
> > between the Action and the JSP Tags (or other View Tools). But, it
> > should *never* go past the Action into another layer.
> >
> > Aside from that key best practice -- the ActionForm should never go
> > past the Action into another layer -- we might as well be discussing
> > how many angels can dance on the head of a pin :)
> >
> > -Ted.
> >
> > On Mar 31, 2005 11:40 PM, atta-ur rehman <at...@gmail.com> wrote:
> >
> >>Dea all,
> >>
> >>I'm sure I've seen this topic before! Just can't remember where and
> >>google won't help either! Can anybody please explain which MVC layer
> >>form belongs?
> >>
> >>TIA.
> >>
> >>ATTA
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > For additional commands, e-mail: user-help@struts.apache.org
> >
> >
> >
> >
> >
>
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Which MVC Layer ActionForm Belongs To?
Posted by Ted Husted <te...@gmail.com>.
On Apr 1, 2005 8:53 AM, Frank W. Zammetti <fz...@omnytex.com> wrote:
> Perhaps that's a politician's answer, avoid giving a real answer to a
> sticky question :) but I actually feel like that fits the evidence, so
> to speak. Depends on what the definition of "is" is I guess :)
OK, since we've had theological, historical, and political answers,
how about a scientific one?
Asking what MVC layer an ActionForm belongs is a bit like asking if
H2O is a solid, liquid, or gas. :)
When the Action populates it from the request, it is interpreting the
user gestures, and the ActionForm is part of the Controller. When the
Action populates it from the database, it represents the state of the
application, and the ActionForm is part of the Model. When a JSP Tag
merges the its data into the page, the ActionForm is used as a helper
class that is part of the View.
At some point in its lifecycle, an ActionForm is all three.
Albeit, the JSP tags don't care if the bean is an ActionForm or not.
Likewise, the database shouldn't care if the bean is an ActionForm or
not. The only member that cares whether the bean is an ActionForm
instance, is the Action. Since the ActionForm is tightly coupled to
the Action, and loosely coupled everywhere else, I'd say, ipso facto,
like its friend the Action, the ActionForm is a card-carrying member
of the Controller layer.
But the mileage in your cyclotron may differ :)
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Which MVC Layer ActionForm Belongs To?
Posted by Ted Husted <te...@gmail.com>.
On Apr 1, 2005 11:31 AM, Joe Germuska <Jo...@germuska.com> wrote:
> You have a point, Frank, but more importantly, people have to
> remember that the original MVC pattern applied to an event driven
> unified runtime environment, not a request/response environment.
Back when we were writing Struts In Action, I did correspond with the
originator of MVC, Trygve Reenskaug. He told me that, in his opinion,
the Observer pattern is not required by MVC. It was simply an
implementation detail. What's essential is that the View is able to
render itself from a representation of the Model, as we do with the
JavaBeans strategy.
Subscribing to an object that is watching the database for state
changes, and then apprising subscribers when a change occurs, is one
way to implement MVC. Posting a the "Model" to the servlet context as
a set of JavaBeans is another.
The key points are that the View is a passive client of the
application state, and that the state representation ("model") is
generic. The View is not running out and querying the database
directly, and the data provided by the model could by different views.
(Could be a web page, could be a PDF, could be a pie chart, could be
a bar chart.)
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Which MVC Layer ActionForm Belongs To?
Posted by Joe Germuska <Jo...@Germuska.com>.
>About the ActionForms... I don't personally consider them part of
>either layer. Tangentially, the same goes for Value Objects. They
>straddle the line between two layers in my mind. They are the
>channel through which the view communicates with the control layer,
>and Value Objects are the channel through which the control layer
>communicates with the model. Hence, I don't consider them part of
>either layer. Perhaps we should stop calling it MVC and instead
>call it M+V+C, with the + signs indicating those channels. :)
You have a point, Frank, but more importantly, people have to
remember that the original MVC pattern applied to an event driven
unified runtime environment, not a request/response environment.
That doesn't mean that web development hasn't gotten a whole lot
better since people started building frameworks and calling them MVC
frameworks -- just that the mapping gets a bit warped when you try
too hard to make it all hold together.
With a full rich-client browser experience (this AJAX stuff), you
might be able to build something which more properly implemented the
MVC model, just using HTTP as the event passing transport -- but
requests and responses are not the same as events.
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Which MVC Layer ActionForm Belongs To?
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
"...we might as well be discussing how many angels can dance on the head
of a pin"
639. 704 if they all go to LA Weight Loss for 3 months. But either way
that assumes they haven't been drinking, otherwise they won't be able to
keep their balance long enough to count. I believe this research was
done at AMD development labs in coming up with the Athlon 64. But I
couldn't find a reference online.
(Ahem. There goes my standup career.)
About the ActionForms... I don't personally consider them part of either
layer. Tangentially, the same goes for Value Objects. They straddle
the line between two layers in my mind. They are the channel through
which the view communicates with the control layer, and Value Objects
are the channel through which the control layer communicates with the
model. Hence, I don't consider them part of either layer. Perhaps we
should stop calling it MVC and instead call it M+V+C, with the + signs
indicating those channels. :)
Perhaps that's a politician's answer, avoid giving a real answer to a
sticky question :) but I actually feel like that fits the evidence, so
to speak. Depends on what the definition of "is" is I guess :)
Frank
Ted Husted wrote:
> Well, you know, an ActionForm is what it is. :)
>
> On this list, most people will tell you it belongs to the View.
>
> Other frameworks with similar architectural members call gizmos like
> ActionForms the "Model". Why? Because in classic MVC, the View
> subscribes to the Model, most often as an Observer. In a conventional
> Model 2 application, the View acquires data from the servlet contexts
> --- meaning the servlet contexts become the M in MVC. The JSP Tags
> "observe" critters like the ActionForm in the servlet contexts, hence,
> the argument would go, it's part of the Model. Snagging data from the
> contexts is not quite the Observer pattern, but it does have the same
> effect.
>
> Of course, since most, or all, of that data actually comes from a
> database, a lot of people tend to think of the database as the Model.
> And, in the big picture, the database usually is the one-true Model.
> But from the narrow perspective of Model-2 MVC, the JavaBeans we stuff
> into the servlet contexts do become, for all intents and purposes, the
> Model.
>
> One way to think of it is that our Views aren't designed to gaze upon
> the Model directly. So, the Controller creates a specialized form of
> the Model and places that chunk in the servlet context, where the
> Views can see it. From the View's perspective, the dynamic data in the
> servlet contexts is the Model. (Even though we know it's just a
> runtime snapshot of one sliver of the most-high database Model.)
>
> As to ActionForms in particular, personally, I consider everything in
> the Struts core (Action package) to be part of our Controller layer.
> The taglibs are our View, but the rest, including the ActionForm, is
> part of the Controller. The Controller simply shares the ActionForm
> with the View by putting it the Servlet context (so it becomes part of
> the Model as observed by the View).
>
> Of course, in the end, it doesn't really matter. The ActionForm is
> what the ActionForm is. The one thing it is not, is a business object.
> The Controller creates it from the request, and it bounces around
> between the Action and the JSP Tags (or other View Tools). But, it
> should *never* go past the Action into another layer.
>
> Aside from that key best practice -- the ActionForm should never go
> past the Action into another layer -- we might as well be discussing
> how many angels can dance on the head of a pin :)
>
> -Ted.
>
> On Mar 31, 2005 11:40 PM, atta-ur rehman <at...@gmail.com> wrote:
>
>>Dea all,
>>
>>I'm sure I've seen this topic before! Just can't remember where and
>>google won't help either! Can anybody please explain which MVC layer
>>form belongs?
>>
>>TIA.
>>
>>ATTA
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
>
>
>
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Which MVC Layer ActionForm Belongs To?
Posted by atta-ur rehman <at...@gmail.com>.
Okay, Leon,
Now I got to PRINT this and read before I speak!
Many thanks for your time and thoughts.
ATTA
On Apr 1, 2005 5:24 AM, Leon Rosenberg <st...@anotheria.net> wrote:
> On Fri, 2005-04-01 at 05:14 -0800, atta-ur rehman wrote:
> > Leon,
> >
> > Thanks for your thoughts.
> >
> > I just convinced myself that thinking ActionForm as a part of
> > Controller made most sense! Having said that, I'll be thinking more
> > about your point of view.
> >
>
> :-)))
> If you feel comfortable with it :-)
>
> but maybe you should check out this:
>
> The MVC architecture has its roots in Smalltalk, where it was originally
> applied to map the traditional input, processing, and output tasks to
> the graphical user interaction model. However, it is straightforward to
> map these concepts into the domain of multi-tier enterprise
> applications.
>
> * Model - The model represents enterprise data and the business
> rules that govern access to and updates of this data. Often the
> model serves as a software approximation to a real-world
> process, so simple real-world modeling techniques apply when
> defining the model.
> * View -The view renders the contents of a model. It accesses
> enterprise data through the model and specifies how that data
> should be presented. It is the view's responsibility to maintain
> consistency in its presentation when the model changes. This can
> be achieved by using a push model, where the view registers
> itself with the model for change notifications, or a pull model,
> where the view is responsible for calling the model when it
> needs to retrieve the most current data.
> * Controller - The controller translates interactions with the
> view into actions to be performed by the model. In a stand-alone
> GUI client, user interactions could be button clicks or menu
> selections, whereas in a Web application, they appear as GET and
> POST HTTP requests. The actions performed by the model include
> activating business processes or changing the state of the
> model. Based on the user interactions and the outcome of the
> model actions, the controller responds by selecting an
> appropriate view.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Which MVC Layer ActionForm Belongs To?
Posted by Leon Rosenberg <st...@anotheria.net>.
On Fri, 2005-04-01 at 05:14 -0800, atta-ur rehman wrote:
> Leon,
>
> Thanks for your thoughts.
>
> I just convinced myself that thinking ActionForm as a part of
> Controller made most sense! Having said that, I'll be thinking more
> about your point of view.
>
:-)))
If you feel comfortable with it :-)
but maybe you should check out this:
The MVC architecture has its roots in Smalltalk, where it was originally
applied to map the traditional input, processing, and output tasks to
the graphical user interaction model. However, it is straightforward to
map these concepts into the domain of multi-tier enterprise
applications.
* Model - The model represents enterprise data and the business
rules that govern access to and updates of this data. Often the
model serves as a software approximation to a real-world
process, so simple real-world modeling techniques apply when
defining the model.
* View -The view renders the contents of a model. It accesses
enterprise data through the model and specifies how that data
should be presented. It is the view's responsibility to maintain
consistency in its presentation when the model changes. This can
be achieved by using a push model, where the view registers
itself with the model for change notifications, or a pull model,
where the view is responsible for calling the model when it
needs to retrieve the most current data.
* Controller - The controller translates interactions with the
view into actions to be performed by the model. In a stand-alone
GUI client, user interactions could be button clicks or menu
selections, whereas in a Web application, they appear as GET and
POST HTTP requests. The actions performed by the model include
activating business processes or changing the state of the
model. Based on the user interactions and the outcome of the
model actions, the controller responds by selecting an
appropriate view.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Which MVC Layer ActionForm Belongs To?
Posted by atta-ur rehman <at...@gmail.com>.
Leon,
Thanks for your thoughts.
I just convinced myself that thinking ActionForm as a part of
Controller made most sense! Having said that, I'll be thinking more
about your point of view.
Regards,
ATTA
On Apr 1, 2005 4:59 AM, Leon Rosenberg <st...@anotheria.net> wrote:
> On Fri, 2005-04-01 at 06:01 -0500, Ted Husted wrote:
> > Well, you know, an ActionForm is what it is. :)
> >
> > On this list, most people will tell you it belongs to the View.
> >
>
> To shorten Ted's post:
>
> This depends on your viewpoint. Inside the presentation layer it's 100%
> the model. If you are talking about the presentation layer, refer to
> ActionForm as Model.
>
> If you are talking about the system architecture, the whole presentation
> layer is a view on the business layer. In this case ActionForm is part
> of the view.
>
> regards
> Leon
>
> > Other frameworks with similar architectural members call gizmos like
> > ActionForms the "Model". Why? Because in classic MVC, the View
> > subscribes to the Model, most often as an Observer. In a conventional
> > Model 2 application, the View acquires data from the servlet contexts
> > --- meaning the servlet contexts become the M in MVC. The JSP Tags
> > "observe" critters like the ActionForm in the servlet contexts, hence,
> > the argument would go, it's part of the Model. Snagging data from the
> > contexts is not quite the Observer pattern, but it does have the same
> > effect.
> >
> > Of course, since most, or all, of that data actually comes from a
> > database, a lot of people tend to think of the database as the Model.
> > And, in the big picture, the database usually is the one-true Model.
> > But from the narrow perspective of Model-2 MVC, the JavaBeans we stuff
> > into the servlet contexts do become, for all intents and purposes, the
> > Model.
> >
> > One way to think of it is that our Views aren't designed to gaze upon
> > the Model directly. So, the Controller creates a specialized form of
> > the Model and places that chunk in the servlet context, where the
> > Views can see it. From the View's perspective, the dynamic data in the
> > servlet contexts is the Model. (Even though we know it's just a
> > runtime snapshot of one sliver of the most-high database Model.)
> >
> > As to ActionForms in particular, personally, I consider everything in
> > the Struts core (Action package) to be part of our Controller layer.
> > The taglibs are our View, but the rest, including the ActionForm, is
> > part of the Controller. The Controller simply shares the ActionForm
> > with the View by putting it the Servlet context (so it becomes part of
> > the Model as observed by the View).
> >
> > Of course, in the end, it doesn't really matter. The ActionForm is
> > what the ActionForm is. The one thing it is not, is a business object.
> > The Controller creates it from the request, and it bounces around
> > between the Action and the JSP Tags (or other View Tools). But, it
> > should *never* go past the Action into another layer.
> >
> > Aside from that key best practice -- the ActionForm should never go
> > past the Action into another layer -- we might as well be discussing
> > how many angels can dance on the head of a pin :)
> >
> > -Ted.
> >
> > On Mar 31, 2005 11:40 PM, atta-ur rehman <at...@gmail.com> wrote:
> > > Dea all,
> > >
> > > I'm sure I've seen this topic before! Just can't remember where and
> > > google won't help either! Can anybody please explain which MVC layer
> > > form belongs?
> > >
> > > TIA.
> > >
> > > ATTA
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > For additional commands, e-mail: user-help@struts.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Which MVC Layer ActionForm Belongs To?
Posted by Leon Rosenberg <st...@anotheria.net>.
On Fri, 2005-04-01 at 06:01 -0500, Ted Husted wrote:
> Well, you know, an ActionForm is what it is. :)
>
> On this list, most people will tell you it belongs to the View.
>
To shorten Ted's post:
This depends on your viewpoint. Inside the presentation layer it's 100%
the model. If you are talking about the presentation layer, refer to
ActionForm as Model.
If you are talking about the system architecture, the whole presentation
layer is a view on the business layer. In this case ActionForm is part
of the view.
regards
Leon
> Other frameworks with similar architectural members call gizmos like
> ActionForms the "Model". Why? Because in classic MVC, the View
> subscribes to the Model, most often as an Observer. In a conventional
> Model 2 application, the View acquires data from the servlet contexts
> --- meaning the servlet contexts become the M in MVC. The JSP Tags
> "observe" critters like the ActionForm in the servlet contexts, hence,
> the argument would go, it's part of the Model. Snagging data from the
> contexts is not quite the Observer pattern, but it does have the same
> effect.
>
> Of course, since most, or all, of that data actually comes from a
> database, a lot of people tend to think of the database as the Model.
> And, in the big picture, the database usually is the one-true Model.
> But from the narrow perspective of Model-2 MVC, the JavaBeans we stuff
> into the servlet contexts do become, for all intents and purposes, the
> Model.
>
> One way to think of it is that our Views aren't designed to gaze upon
> the Model directly. So, the Controller creates a specialized form of
> the Model and places that chunk in the servlet context, where the
> Views can see it. From the View's perspective, the dynamic data in the
> servlet contexts is the Model. (Even though we know it's just a
> runtime snapshot of one sliver of the most-high database Model.)
>
> As to ActionForms in particular, personally, I consider everything in
> the Struts core (Action package) to be part of our Controller layer.
> The taglibs are our View, but the rest, including the ActionForm, is
> part of the Controller. The Controller simply shares the ActionForm
> with the View by putting it the Servlet context (so it becomes part of
> the Model as observed by the View).
>
> Of course, in the end, it doesn't really matter. The ActionForm is
> what the ActionForm is. The one thing it is not, is a business object.
> The Controller creates it from the request, and it bounces around
> between the Action and the JSP Tags (or other View Tools). But, it
> should *never* go past the Action into another layer.
>
> Aside from that key best practice -- the ActionForm should never go
> past the Action into another layer -- we might as well be discussing
> how many angels can dance on the head of a pin :)
>
> -Ted.
>
> On Mar 31, 2005 11:40 PM, atta-ur rehman <at...@gmail.com> wrote:
> > Dea all,
> >
> > I'm sure I've seen this topic before! Just can't remember where and
> > google won't help either! Can anybody please explain which MVC layer
> > form belongs?
> >
> > TIA.
> >
> > ATTA
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Which MVC Layer ActionForm Belongs To?
Posted by Ted Husted <te...@gmail.com>.
Well, you know, an ActionForm is what it is. :)
On this list, most people will tell you it belongs to the View.
Other frameworks with similar architectural members call gizmos like
ActionForms the "Model". Why? Because in classic MVC, the View
subscribes to the Model, most often as an Observer. In a conventional
Model 2 application, the View acquires data from the servlet contexts
--- meaning the servlet contexts become the M in MVC. The JSP Tags
"observe" critters like the ActionForm in the servlet contexts, hence,
the argument would go, it's part of the Model. Snagging data from the
contexts is not quite the Observer pattern, but it does have the same
effect.
Of course, since most, or all, of that data actually comes from a
database, a lot of people tend to think of the database as the Model.
And, in the big picture, the database usually is the one-true Model.
But from the narrow perspective of Model-2 MVC, the JavaBeans we stuff
into the servlet contexts do become, for all intents and purposes, the
Model.
One way to think of it is that our Views aren't designed to gaze upon
the Model directly. So, the Controller creates a specialized form of
the Model and places that chunk in the servlet context, where the
Views can see it. From the View's perspective, the dynamic data in the
servlet contexts is the Model. (Even though we know it's just a
runtime snapshot of one sliver of the most-high database Model.)
As to ActionForms in particular, personally, I consider everything in
the Struts core (Action package) to be part of our Controller layer.
The taglibs are our View, but the rest, including the ActionForm, is
part of the Controller. The Controller simply shares the ActionForm
with the View by putting it the Servlet context (so it becomes part of
the Model as observed by the View).
Of course, in the end, it doesn't really matter. The ActionForm is
what the ActionForm is. The one thing it is not, is a business object.
The Controller creates it from the request, and it bounces around
between the Action and the JSP Tags (or other View Tools). But, it
should *never* go past the Action into another layer.
Aside from that key best practice -- the ActionForm should never go
past the Action into another layer -- we might as well be discussing
how many angels can dance on the head of a pin :)
-Ted.
On Mar 31, 2005 11:40 PM, atta-ur rehman <at...@gmail.com> wrote:
> Dea all,
>
> I'm sure I've seen this topic before! Just can't remember where and
> google won't help either! Can anybody please explain which MVC layer
> form belongs?
>
> TIA.
>
> ATTA
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Which MVC Layer ActionForm Belongs To?
Posted by Hubert Rabago <hr...@gmail.com>.
On Mar 31, 2005 10:40 PM, atta-ur rehman <at...@gmail.com> wrote:
> Dea all,
>
> I'm sure I've seen this topic before! Just can't remember where and
> google won't help either! Can anybody please explain which MVC layer
> form belongs?
>
> TIA.
>
> ATTA
>
So, Atta, so you don't have to google it next time, you can bookmark
these two links:
http://marc.theaimsgroup.com/?l=struts-user&m=111236929125916&w=2
http://struts.apache.org/userGuide/building_model.html#actionform
:)
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org