I, too, am closely following the Model 2 discussions. I greatly appreciate
everybody's input. Thank you!


At 3/28/2000 08:59 AM +0200, Daniel Lopez wrote:
<snip, snip>

>  In my case, I added some more
>complexity in here because, as I want my controller servlet to handle
>various applications, I store a hastable per application. I choose the
>appropriate application depending on the suffix.
>So "Enroll.do", I first get the application corresponding to the ".do"
>suffix and then I got the action factory corresponding to the "Enroll"
>operation from the selected application. Then I get the action from the
>factory.

Would another option be to check the current context (instead of having
multiple suffixes)? (This way everything still routes thru your single
controllerServlet.)

Or, possibly, you could clone your controllerServlet - once for each
application/context - and achieve your separation that way?
Of course, I'm making the assumption that your use of "application" can be
interchanged with a context - is this correct?

>I agree with Craigīs in this one, I also let the Action class (I call it
>Operation) to forward itself to the appropriate place. This option
>allows me to leave the controller servlet code clean of UI redirecting
>code and this allows me to have different Operation classes that behave
>differently. For example, in case I want a special Operation that does
>not use forward but creates the UI itself (useful for some rare cases).

Does it make sense to add a parameter to the perform() function to
represent the target Page? E.g.

public interface Action {
     public void perform(HttpServlet servlet,
                         HttpServletRequest request,
                         HttpServletResponse response
                         String targetPage)
            throws IOException, ServletException;
} // ends interface Action

{BTW, thank you Craig for the above!}

This way the target page is (more) open to configuration (specifically, the
configuration file that links request uri's with java class names, would
also specify the target page. And, of course, only under exceptional
circumstances would the user be redirected back to the request uri, an
error uri, etc.

> > When using Model 2, you already are
> > forced to write the code that gets all the form parameters out of the
> > request object when it comes in (part of the action class I
> > believe..right?)
>
>Yes, some people tend to use the Model 1'5 because it automagically
>populates your beans from the data inside the forms. But thatīs a
>personal choice.
>
> >, and thus, by populating the bean and putting it in the
> > request, the JSP page will most likely use the bean at the request scope,
> > fill in the values of another form (or possibly the same form if say an
> > error occured and the page is being redisplayed) so that a subsequent
> > request will contain those values where need be.
>
>Yes, the idea is to "communicate" the action class(business logic) and
>the JSP(UI view) by putting objects in the request, the session and the
>context.

I think of the action class objects as still part of the controller level
(from Model - View - Controller). Since their role in life is to mediate
between the UI & the Model (your EJB objects, or, as in my case, our Corba
objects, whatever). If your business logic objects have method signatures
including HttpServletRequest and the like, then you're only going to be
accessing them thru a web-based frontend. (Not necessarily a bad thing if
you're a web developer!)

> > Thanks so much for all of your emails. I know its taught me alot and
> > enlightened me on a number of topics I was unclear about. I hope its doing
> > the same for others reading this ongoing discussion.
>
>I hope so as well. Itīs also useful for us as thereīs no such a thing as
>the perfect design and rationalizing it to explain it to others, and
>compare it to other viable solutions are very good ways of "revisiting"
>your design choices. And it also gives me the chance to see that Craig
>and I agree sometimes ;), basically because I learnt most of it from his
>posts and followed his recommended readings :).
>I hope this helps,
>Dan

Yes, this helps big time!! Thank you!

Mike

===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
Some relevant FAQs on JSP/Servlets can be found at:

 http://java.sun.com/products/jsp/faq.html
 http://www.esperanto.org.nz/jsp/jspfaq.html
 http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
 http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets

Reply via email to