Good answer, but I think anyone who asks "why not have the screen classes do all the
work?" might need something more basic. Try:
<http://whatis.techtarget.com/definitionsSearchResults/1,289878,sid9,00.html?query=model-view-controller>
<http://cbl.leeds.ac.uk/nikos/tex2html/examples/concepts/node74.html>
for an introduction to MVC.
And here's some marketing fluff from a document I wrote to convince a client to move
away
from ASP:
------BEGIN MARKETING FLUFF-------------------------------------
We consider HTML templating to be the superior approach to web
development by a long shot. Nothing else comes close. Why? Well, as
discussed in more detail below, development time for both programmers
and designers is essentially reduced over time saving the client
costs, time, and headaches.
Through the use of templating, the development process is divided in a
way that keeps developers and designers focused on what each does
best. For example, a template-based website can be given a complete
facelift without touching a single line of Java code. Only the
templates must be modified.
This division of labor also prevents bugs from creeping into the end
product. Consider what happens when both business and presentation
logic are confined within a single file. The hapless designer, who
has been directed to correct a small error such as a misspelled word,
opens the JSP, ASP, or PHP page in his favorite HTML editor. He sees
a jumbled mixture of HTML and scripting language. The designer fixes
the misspelling, but also accidentally deletes a crucial line of code.
Suddenly, the entire application is broken, and a developer must be
called in to debug the problem.
Template-based architectures also correspond closely to business and
functional divisions in most organizations. Developers work with a
variety of business units while designers work with the marketing
department. Thus, existing business processes are more easily
translated into web applications.
--------END MARKETING FLUFF-------------------------------------
And if you haven't figured it out yet:
action == controller
template == view
Hope that helps.
cheers,
-- Travis Low
<mailto:[EMAIL PROTECTED]>
<http://dawnstar.org/travis>
Jon Stevens wrote:
> on 6/14/01 1:32 PM, "Peter Lynch" <[EMAIL PROTECTED]> wrote:
>
>
>>Hi,
>>
>>Someone asked me why the need to separate action
>>classes from screen class code. In other words, they
>>were wondering why not have the screen classes do all
>>the work? I was brain dead at the time so I think I
>>did not give a very compelling argument why....
>>
>>So can anybody offer some compelling
>>reasons/advantages for this design as opposed to
>>having the screen classes do all the work of putting
>>and getting?
>>
>>Thanks,
>>
>>Peter
>>
>
> MVC.
>
> In other words, the conceptual model behind regular HttpServlets and JSP
> pages is that you submit to the same page, put a big if-statement tree in
> there and figure out what to do depending on what button was pushed. In
> summary, that is a brain dead stupid model to use. The reason is simple: It
> can be done better and easier.
>
> Instead, it is better to section out the Controller and Model from the View.
> In reality, these days, a properly designed application should never have
> *any* Java Screen modules other than potentially a "Default.java" which gets
> executed for every Screen template in a directory. This is called the Pull
> Model.
>
> So, what you are left with is Action modules. I developed the idea of
> ActionEvents which is the concept of tying a <form> button to a method call
> in an Action. This removes the need for a silly if-statement tree to figure
> out which button was pressed. All you need to do is relate a Java method to
> what is supposed to be executed with someone clicks a button. The cool thing
> here is that, if you do it right, Actions are not tied to the template. You
> can re-use an Action across several different pages. For example, if you
> have a "Search" <input type="text"> field on several pages, you don't want
> to have to copy/paste code into each and every Action that is supposed to
> deal with it. Instead, you can make a single Action module and re-use that
> on every screen or make a BaseAction, put your method in it and then have
> whatever Actions you want extend it and get the functionality to be able to
> handle the submit.
>
> Things to read:
> <http://jakarta.apache.org/turbine/pullmodel.html>
> <http://jakarta.apache.org/turbine/howto/action-event-howto.html>
>
> -jon
>
>
> ---------------------------------------------------------------------
> 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]
