Hi Mike,
Mike LaBudde wrote:
>
> 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.)
Well, this could be an option if I were using JSP2.2 where you have a
context per application. On the other hand, if I want to have different
"applications"(set of related actions) under the same context so they
can share some resources, then I need to separate actions from each
"application" and I chose to use the suffixes. I started using the name
"application" before it was introduced in JDSK2.2 but now I might have
to use another name because it leads people to confusion.
Subapplications?
Modules?
> 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 actually clone my controller servlet (using different aliases) to
achieve
separation some logical separation of applications, even though it�s not
mandatory. My use of application cannot be interchanged with a context,
as
I don�t mandate JSDK2.2. I called an application, I would have to change
that damn name ;), a set of related actions that share the security
settings
and an application life cycle, that means that either all of them are
available(app. is started) or none of them is(app. is stopped). That way
I introduced application lifecycle events which allow me to manage
easily
shared resources and the like.
> >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.
Well, I don�t pass it as argument because I already set it when creating
the Action class, but the idea is the same ;). I like the idea, as you
point out, of having the configuration opened in the XML file. OTOH,
this
works well for 90% of the cases so I'm thinking of adding the ability in
the action classes to modify this settings, and have the XML settings as
default, to cover that remaining 10%. I haven�t found such a need yet
and
I don�t really like hardcoding UI logic (choosing the UI) inside the
action
classes but I admit there might be some cases where it could be useful.
Any comments? Oh, I have to add that error handling is, for me, not one
of
the cases where this should used, as I have another parameter for that
;).
> > > 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!)
My mistake :), I should have phrased this better. I agree with you about
the action class not being part of the model, they are not the business
logic. It would have sounded better to say that the idea is to
communicate
the business logic (be it beans, EJB...) with the UI view (be it JSP,
WebMacro...) through the controller( action classes + controller
servlet)
using the provided "channels" (request, session, context). I also like
thinking about 4 layers (persistance, business logic, operational logic,
user interface) when it comes to dividing the work in separate tasks,
but
this is more a personal choice.
> > > 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
Thanks to you for your feedback and remarks,
Dan
-------------------------------------------
Daniel Lopez Janariz ([EMAIL PROTECTED])
Web Services
Computer Center
Balearic Islands University
-------------------------------------------
===========================================================================
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
