"...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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]






-- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com


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



Reply via email to