Hi Tom,
I snipp the part where we agree and I'll intermix my answers to your questions so
this post doesn't get too big:
Tom Eugelink escribi�:
> Ahhh. Interesting discussion! Let me add some opinion also.
>
> > -----Urspr�ngliche Nachricht-----
> > Von: Daniel Lopez [mailto:[EMAIL PROTECTED]]
> >
> > Hi,
> >
> > I'll add some comments of my own.
> >
> > Kevin Duffey escribi�:
> >
> > If you have to perform some logic, like checking if the user has
> > performed all the
> > necessary previous steps to do what he wants to do, I'd still
> > go through the controller - action - view pattern.
>
> When the user has accepted the data in the form, you should go through the
> controller. Otherwise you can step anywhere, because there is nothing to
> process. Consider what happens if the user uses "previous" and "forward" in
> the browser to your controller workflow.
Well, if he wants to use the browser buttons, I don't care. But if I have to let
him use
an explicit link, I'd always (or 99% of the times ;) ) use the whole controller
roundtrip.
For a couple of reasons, first one: coherence. I'm not confortable with the idea of
having
some links that end up in ".go" or ".do" and some with ".jsp" so some go through
the whole
model and some don't. Just a matter of taste. Second, cautiousness, as Craig also
mentioned
in another posting, if you show them the straight URL to get to your JSP pages you
are tempting
both your designers and your users to use them when they shouldn't. In this case
I'd rather use
the paranoid approach that Craig mentioned. Third: I you are worried about
performance, the
"previous" URL can contain a special parameter (or use the absence of any parameter
as flag)
to tell the action itself that it doesn't have to retrieve again the information
but just forward to
the appropriate JSP and let this page get the "previous" results from the session.
But the are all pretty much a matter of taste so use what you like, just be sure
that you have
your own reasons to do it the way you are doing it.
> > > I do. I have a JSP page per form that is to be displayed.
> > And I have an
> > > action per form. You can have multiple forms submit to the
> > same action, but
> > > then you'll need some sort of hidden command code system to
> > figure out the
> > > specific action to take.
> >
> > Exactly. You can also use the same JSP for different actions which is
> > one of the advantages
> > of using model 2, the URL looks different but the JSP is the same but
> > after performing a
> > different action.
>
> Hmmm. Does this mean an action equals a command bean? When can I get a quick
> summary of this concept? I've worked out a system based on request based
> workflow beans and wrapper pages (posted already to this list).
I'm not sure what you mean exactly with "a command bean" but if you are talking
about
the command pattern, you are right. I use this model inspired (I had thought about
it before
but I in't have a name for it)by the command pattern. Answering your other posting
about workflows... I prefer having the workflow configured through property files
(in my case
XML files) because it allows me to change the workflow without recompiling classes.
I just need
to reload the configuration an that's it. And it's also easier to "read" an "debug"
than having to
check inside Java classes. Somebody also suggested using a database to store the
workflow
and retrieve the JSP to forward to from the DB on every request after performing
the request.
In our case, we tried not to complicate things so much for performance reasons and
because
we thought the workflow shouldn't be so dynamic and complicated as to require a
database backend.
But I admit that in some cases where the app. is very big and workflow is difficult
to grasp, it would
be quite helpful to use this DB to debug easily 404 Errors or "Which actions use
this JSP page?" queries...
But hardcoding workflow in any kind of java class (actions, beans, even special
classes just dedicated to that)
.... I wouldn't recommend it for mantainability's sake.
Just another 2c,
Dan
>
> Tom
>
> ===========================================================================
> 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
===========================================================================
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
