I just read this sorta quickly, but I think I understand the situation.
Two things...
1) I've been looking at patterns that _minimize_ the amount of java code
in JSP files. This way they just do presentation -- no "business" logic.
(Btw, Its been a bit of a chore keeping the ex-perl/php developers from
dropping reams of inline java code into JSP files!)
Hence, I would consider moving the lookup for the order out of the
JSP and into a servlet that forwards to a presentation JSP.
One pattern I've experimenting with has the request (post or get)
to the servlet also specify the "success" jsp and "failure" jsp.
All the presentation JSP does is display the order(s). It may require an
Iterator to display all items in an Order object (the order object could
implement the Iterator interface -- I leave it up to you to decide.)
2) Regarding where to put the Order Object....
What's the problem with putting the Order object (actually an
Order instance, right?) in the session as opposed to the request?
Having the Order instance in the session seems very natural to me.
Eg, the Order instance will follow the user around the site (or at
least related pages), and will always be available.
Afaik, the request instance (and response instance) are GC'ed and
no longer available once the response is sent to the client.
3) Regarding encoding the "orderid" in the url. I suppose if you
have multiple orders that you are managing on a single page
you need to have a way of saying which order to do the delete
operation on. However, ask yourself if you are "trusting the
client" to tell you which order to process.
Eg, can someone spoof your app by typing in a different
orderid on the query string for delete? (Maybe this isnt
an issue; I've seen this sort of non-obvious security
holes in other apps I've worked on.... by other programmers
of course!)
Instead, I suppose you could have a vector of orders which is
kept in the session. The URL specifies which element in the
vector that should be deleted.
Yes, this is an additional indirection, but if it solves a security
problem then its worth it.
Alternatively, I suppose you could make sure the session is
authorized to delete the order that the request is trying to delete.
But then that's yet another table, or in memory vector, etc.
Hope this helps! I feel like I didnt answer your orginal question!
Of course, since I'm not familiar with your application, I could be
way off in left field with my suggestions.
>From: Robert Nicholson <[EMAIL PROTECTED]>
>To: JSP-INTEREST <[EMAIL PROTECTED]>; Taglibs-User
><[EMAIL PROTECTED]>
>Date: Saturday, September 23, 2000 10:18 PM
>Subject: Questions about a common usage pattern.
>
>Since folks in this group have a high appreciation of separating business
>logic from presentation. I want to ask about a common usage pattern that
>comes up in web applications and seek advice on a better way to go about
>things.
>
>Imagine you have a list orders page which lists orders ... you then click on
>an order and it brings you to a "edit order" page where you can see the
>details about the order and the detail items for the order. You can delete
>detail items from the order.
>
>My questions relate to when, where and how, you gain access to the "order"
>object. The business object that represents your order.
>
>Currently I have this structured such that when you see a list of orders on
>the list order page you see a hyperlink who's url encodes an OrderID and
>this url goes to a controller jsp page. In this controller jsp page I look
>up the order based on the OrderID and fetch an Order object. I then use
>request dispatcher to put this order object in the request and forward to a
>page that presents the order and it's detail information to the user.
>
>The problem for me was when I started to think about what would happen after
>I've deleted my order items. When I do this I shouldn't have to refetch
>anything from the database since what's in memory will be kept in sync with
>what's in the database. However, after I've deleted my order items I will
>want to refresh the page and hence I will need all the Order information to
>draw the page.
>
>If I don't keep the object in the session in this scenario how do I get the
>order from the page where I viewed it to make the change to the same page
>after I've deleted an order item. I will delete an order item by selecting
>checkboxes for each other item and pressing a delete button. So upon
>submitting this form I then lose the reference to my Order unless it's in
>the session. I had the Order when I layed out the view page but when you
>submit the form over to another "controller" page you've lost the Order
>reference all together. So you had it as a request attribute before but now
>it's gone because it's a new request.
>
>My question is after the action to the form that handles the deletions of
>the detail item is processed how then can I gain access to my "Order" object
>so that I can show it's newly updated details again.
>
>Can somebody propose ways of gaining access to the Order object again
>without cluttering up the session with it? Right now I changed my code to
>eliminate the controller so that when you see a list of orders the page that
>views the orders simply will have to do the fetch from the database based on
>the OrderID encoded in the URL to get here in the first place. ie. the
>controller that took care of the delete will dispatch back to the view page
>when it's finished. So it's expected that any page that leads to this view
>order page will add the OrderID in the URL and a fetch will occur. I don't
>like having to structure it this way.
>
>There aren't any Form bean objects in this scenario what gets displayed is
>directly from the Order object that represents the Data from the "object
>graph" in the database.
>
>I want to understand if it's possible to keep the Order object around in the
>request that's chained so that it's available when I come back to the view
>order page. I don't think it is and I think I'm forced to keep it in the
>session with this model2 style architecture arrangement.
>
>
>
>
>
>
>---
>Robert Nicholson
>Email: [EMAIL PROTECTED]
>AOL : rydmerlin
>
===========================================================================
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
