× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Larry,

I don't think persistent CGI programs ever really caught on and I'm pretty sure there are scalability issues there (I think the issue is it starts a CGI job for each user). I've seen additional posts about using a session id and that's a pretty good way to go. One other possibility is to use the buyer's user name as the key to the order information if you are not going to allow anonymous shopping (you can usually only get away with that in a B2B environment).

The next question (assuming using the user name isn't going to work) is what to use as the key. You can use a next number routine but that has security implications since it makes the key easily guessable. For this type of thing, I like using a UUID. There is an MI called _GENUUID (search the archives for examples) that will generate a 16 byte unique id that's theoretically unique across all computers (this is pretty random so it address the easy to guess issue). What it generates is a binary number which will contain unprintable characters when you convert it to a character value so the typical way to handle this is to convert it to hex. Once it's converted, you can store the value as a cookie. Another option is to use _CIPHER to generate a secure random number (this also generates a binary value you'll need to convert to hex).

Once you have the key figured out, I would persist the data in files you create on the system. I wouldn't even bother with a session data table (unless you need something to tie a session id to a particular user) and create header and detail files. This is far, far easier than trying to manage things in memory (which limits scalability) or passing it around in forms or on URLs. One thing you'll need to do (especially if you are in a B2C environment) is have some way to purge old data from the files. A last updated field makes that easy to do.

Matt

-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Larry Kleinman
Sent: Thursday, March 06, 2008 4:26 PM
To: Web Enabling the AS400 / iSeries
Subject: Re: [WEB400] shopping cart in net.data


Thanks for the quick response. I agree, net.data does not do complicated
well. I apologize for not being specific. Most of the logic will be done
via calls to RPG programs (since most of these already exist). I think that
what is hanging me up is the ability to keep a single "transaction" while
going from screen to screen. In "green screen days" this would be simple -
an order number in an order header file, that is associated with all of the
items (in an order detail file). My problem is going to be keeping track of
this order number as we go from screen to screen (sometimes via HREF,
sometimes via SUMBIT). I'd rather not be passing this number as part of the
URL. I know net.data has the ability to do a persistent function, but the
documentation that I've seen for this is a nightmare. Is this the direction
- other than something like PHP which I do not yet know well enough to deal
with - that makes sense? If so, do you know where I might find some
examples of persistent macros?




Larry Kleinman
Kleinman Associates, Inc.
212-949-6469
203-255-4100



"Haas, Matt (CL
Tech Sv)"
<matt.haas@cengag To
e.com> Web Enabling the AS400 / iSeries
Sent by: <web400@xxxxxxxxxxxx>
web400-bounces@mi cc
drange.com
Subject
Re: [WEB400] shopping cart in
03/06/2008 04:16 net.data
PM


Please respond to
Web Enabling the
AS400 / iSeries
<web400@midrange.
com>






Larry,

This can be done. In fact, IBM used to sell a product called Net.Commerce
(this is now called WebSphere Commerce Suite and is written in Java) that
did this very thing. The way they did it was to handle all of the
programming logic in native code and use Net.Data just for the display. IBM
gave us a demo of this (that was around 1998) and the code was very, very
ugly.

Depending upon what you're doing, shopping carts can be pretty complicated
and it's been my experience that Net.Data doesn't do complicated very well.

We (as in mostly me) ended up writing CGI programs to do all of this that
wrapped our order entry logic (the validation part is where it gets tricky,
the act of taking a product id and putting it in a table is easy). If I were
doing this today and didn't want to use Java, I probably would use one of
the tool kits (like CGIDEV2).

Another option would be to use PHP. There are plenty of examples in PHP to
get you started. Most of the ones I've seen lacked the sophistication you'd
expect of a production app but they would be a place to start.

Matt

-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx] On
Behalf Of Larry Kleinman
Sent: Thursday, March 06, 2008 3:58 PM
To: WEB400@xxxxxxxxxxxx
Subject: [WEB400] shopping cart in net.data


Has anyone done a shopping cart in Net.data? I've done a lot of work with
net.data, but never a cart. I'm about to start one, but if someone knows
any samples, freeware, etc out there, I'd rather not start from scratch.
Thanks


Larry Kleinman
Kleinman Associates, Inc.
212-949-6469
203-255-4100
--
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.


--
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.