AndySoft wrote:
> > Beans are very useful for lots of things, but managing flow of
> > control is not
> > one of them. The requirement to direct the flow of control, based on user
> > input, is very common.
>
> yep, i do stuff like this
>
> > Consider the scenario I described earlier (enter filter criteria
> > on a customer
> > search screen). Add an additional application requirement -- if the user
> > specified no criteria at all (and would thus select the entire customer
> > database), or they specified inconsistent data (such as backwards
> > dates on a
> > date range), the user should be returned to the input form and see an
> > informative error message plus the values they have already
> > entered, if any, so
> > that they can correct and resubmit. If all the criteria look OK, the
> > application should do the search and display the first page of
> > the results.
>
> hmm, i use a flag for this, and in the jsp the first thing gets checked is
> this errorflag, if it's set then the request is sent back to the initial
> page where the already entered fields will be filled from the previous
> values, maybe it's better with servlets i just don't like how the session is
> handled and don't like the fact that the servlet is another page-object in
> the history, so when users press back button in the browser then it displays
> error to them, with jsp that never happens, right?
>
Not quite.
When you use either <jsp:forward> or RequestDispatcher.forward(), the browser
never sees it as a page event or anything else -- the browser is oblivious to
the fact that it happened. In fact, the URL they submitted to (that of the
servlet, in my approach) still shows even though the page itself was really
created by a JSP.
It sounds like you are using sendRedirect() to send the user back in the error
case. Try using <jsp:forward> instead.
What's different about session handling? It's all the same stuff underneath.
You grab the current session by saying:
HttpSession session = request.getSession();
which, coincidentally, is exactly what the generated code for your JSP does.
>
> but as i said it's all personal choice and preference
>
For your own code, it's certainly personal preference.
When you're being paid to write code for someone else, and you make a design
choice that has a material impact on the maintainability of that code (and,
therefore, the cost of making functionality changes later), you need to make
sure you understand the priorities of the company paying the bill for your
programming talents. If they care about maintainability, then you had better
care also.
Craig
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
FAQs on JSP can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
