|
Home > Archive > WebSphere Commerce suite > April 2005 > Help with persisting data across multiple commands/views
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Help with persisting data across multiple commands/views
|
|
|
| Hello,
First off let me say that this question might be very basic and I
apologize if it seems like a "dumb" question.
I am trying to determine the "best practices" method for persisting
data across multiple commands and views. I am running WCS 5.4 if it
makes a difference for this question (I don't see how it would and if
it does I'm curious to know why). I should note that the only sample
store that I have looked at is InFashion and that the sites I have
made are loosely based off of this sample store. A modified InFashion
store was provided as part of an integration to a backend which
functions as the system of record. I say this as a preemptive answer
to the question of why I am using InFashion.
Currently I rely almost exclusively on persisting data through forms
and URL parameters. I even carry the order_id through the URL. The
sites that I am working on are becoming large and I want to get a
handle on this before I reach a point where it is too costly to go
back and redesign everything. I am looking for any advice on how to
persist data between pages. Any level of advice will be greatly
appreciated.
I do understand that I will always have to persist some data by
passing it as parameters. However, my understanding is that this
method is better suited for parameters that determine how a page
should be displayed. I don't think that it is a great idea to pass a
parameter obtained in page A through pages B, C, D for the sole
purpose of allowing page E to use it.
Here are the options that I have come up with:
1. Persist to the session: Get the session through the request object
and save some of the data directly to the session.
2. Persist to the database: Obtain the session id and use it as a key
in a custom table that will store parameters that are currently
carried through all pages.
3. Continue to persist all data through the use of forms and URL
parameters.
Thanks for taking the time to read and possibly respond.
- John
| |
| Robert Brown 2005-04-01, 6:02 pm |
| > Hello,
>
> First off let me say that this question might be very basic and I
> apologize if it seems like a "dumb" question.
>
> I am trying to determine the "best practices" method for persisting
> data across multiple commands and views. I am running WCS 5.4 if it
> makes a difference for this question (I don't see how it would and if
> it does I'm curious to know why). I should note that the only sample
> store that I have looked at is InFashion and that the sites I have
> made are loosely based off of this sample store. A modified InFashion
> store was provided as part of an integration to a backend which
> functions as the system of record. I say this as a preemptive answer
> to the question of why I am using InFashion.
>
> Currently I rely almost exclusively on persisting data through forms
> and URL parameters. I even carry the order_id through the URL. The
> sites that I am working on are becoming large and I want to get a
> handle on this before I reach a point where it is too costly to go
> back and redesign everything. I am looking for any advice on how to
> persist data between pages. Any level of advice will be greatly
> appreciated.
>
> I do understand that I will always have to persist some data by
> passing it as parameters. However, my understanding is that this
> method is better suited for parameters that determine how a page
> should be displayed. I don't think that it is a great idea to pass a
> parameter obtained in page A through pages B, C, D for the sole
> purpose of allowing page E to use it.
>
> Here are the options that I have come up with:
>
> 1. Persist to the session: Get the session through the request object
> and save some of the data directly to the session.
My preference for large objects needed across the store flow. Not just
for performance reasons but also to avoid the GET limitation of 1K that
some of my past clients have run into. I've also seen JSP code break
because of multiple NVPs in the environment (i.e., the NVP list has the
storeId value more than once and one storeId NVP has the store number
and the other NVP does not) and you have no control over which value is
used by the web controller. Scary and a bear to debug since repetitive
tests are typically inconclusive.
> 2. Persist to the database: Obtain the session id and use it as a key
> in a custom table that will store parameters that are currently
> carried through all pages.
Easy to map data to the custom fields and pull the values out on later
JSPs as needed. A new table would require additional work to support
and is probably warranted if the amount of data you intend to save is
large. Lots of places to store shopper data at the user level in
USERDEMO, ADDRESS, etc. though.
> 3. Continue to persist all data through the use of forms and URL
> parameters.
I even dislike the necessity of the IBM supplied sample stores that rely
on langId, storeId, etc. in a single store, single language environment.
Much safer implementation to remove those NVPs and hardcode in a
common include file. This avoids the possibility of hackers looking for
a security hole or perhaps regular users hitting an error because a page
lost the storeId value and your store's task command did not get
executed several pages downstream (the task command for storeId 0 was
executed instead). Trying to start with a sample store and modifying
what IBM provided to rid yourself of these NVPs is no easy endeavor.
Overall, I prefer NVPs for page to page communication but not for action
or behavior beyond that, like to page 3.
> Thanks for taking the time to read and possibly respond.
>
> - John
Just my three cents... Cheers!
R
|
|
|
|
|