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