«

»

Creating a Shopping Cart Example Using Web 2.0 Templates

Of course m-Power & mrc-Productivity Series can create many powerful individual applications. But what if we could combine these templates together using Importing to create a powerful application, like a User Driven Shopping Cart? This documentation will explain the step-by-step process used to create the Crazy Bikes shopping cart, which can be found here.

After adding a few items to my cart, my output screen looks like this:

But this one screen is actually the combination of three separate templates.

THE APPLICATIONS

On the left, I am showing a Web 2.0 Multiple Record Inquiry Template over my Product Master File.

On the same left side, under the Quantity column, I have imported in a very small Web 2.0 Single Record Maintenance Template over a customer built Cart File .

On the right, I have imported a Web 2.0 Work-With Maintenance Template over my Cart File , securing the application by Session ID.

THE MAIN APPLICATION (INQUIRY #20)

Let’s take a peek at what my main HTML view looks like in m-Painter:

As you can see, under the Quantity column, I am importing Maintenance #20 (my very small Maintenance Application), automatically passing it AVK, to automatically update without prompting. (More information about this topic can be found here ). I am also passing it the Session ID. The session ID is essentially the browser’s thumbprint and allows us to run the shopping cart concurrently for multiple users. This Session ID is critical for the success of the application. Without it, my shopping cart contents would be combined with everyone else’s shopping cart who is browsing at the same time.

I am also passing the Product Number, so we know which product the user has selected. Lastly, I am passing the Product Class (Bicycles, Accessories, Clothing), so the page will be able to reload on the correct Product Class Page (Fore example, If a user buys a bicycle, we want the page to refresh to the bicycles page, not the accessories).

The right column was slightly cut off above, so I will print it below in it’s entirety:

Maintenance #30, happens to be my Web 2.0 Work-with Maintenance Template. This shows me the current contents of my shopping cart.

Note: To do limitations within HTML, mrc recommends disabling Advanced Search and Sort from this portion of the Application. Further, you need to go into the Source and Delete the two lines that begin with

&

. Not doing this will cause your shopping cart to function improperly.

THE SHOPPING CART FILE

Your Shopping Cart file is your working file that tracks user input and stays with the customer during their session. This file can consist of as many fields as you would like, however there are some fields that are a necessity (Such as a Session ID or User Name). I will include the fields we utilized below:

THE MAINTENANCE APPLICATIONS

Maintenance #20 is the very small maintenance applications that serves the purpose of allowing users to add records to their cart. In m-Painter, it looks something like this:

Maintenance #30, the Work-With Maintainer, it slightly more complicated. In m-Painter it looks like this:

Needing users only to remove items once they are added to the cart, I have removed all of the Work-With options, except for delete. I have also customized the error message so that when no records show, I show the users a more specific error message than the standard, default one.

You can also see, that I am importing in Maintenance #22. Maintenance #22 is an exact copy of Maintenance #20, except the button text is different. Because of this you can see I pass the same exact parameters to it as I did to Maintenance #20.

I have also painted in a hyperlink at the bottom that allows my users to go to the Checkout page (Report #20) when finished (more on that next).

There were two noteworthy changes to this page:

1) I changed the Application Properties to Secure only by Session ID. This, again, allows for concurrent users as my Session ID is given by the browser and will be unique from all other users. This can be specified in Application Properties -> SQL Statement -> Secure by Session ID.

2) I painted the delete button to behave slightly differently. By default, the delete would simply delete the record then try to reload Maintenance #30 alone. Instead, I needed to keep the Shopping cart look, so I changed the Delete button, in the source, to look like this:

The HREF location now says to automatically delete the record (DVK), that corresponds to the session ID and the Product # (both of which are key fields for this application) and automatically redirect me to I00020 (The main Retrieval), passing along the appropriate Class.

THE FINALIZE SHOPPING SCREENS

This is the output screen to finalize my shopping cart. This application is a Report (Report #20), which has a Maintenance Application (Maintenance #40 painted into it. In m-Painter, my application looks like this:

The Report is fairly straight forward. This screen allows us to visually confirm the order. I can go back and add more things and not lose my cart because my Session ID will be consistent through the whole process. Again, like Maintenance #30, it is being secured by the session ID. To repeat, this ensures that I do not accidentally see other users Shopping carts. I then Import Maintenance #40.

Maintenance #40 looks like this in m-Painter, and will give us the finalizing option:

Steps 2 through 4 allow user input. Option #4 contains a small section of JavaScript that will determine if an e-mail address contains the correct syntax. If you are interested in said code, mrc Hotline can point you in the right direction. The Order Calc, Session ID, and User ID are not needed to be seen by the user but are critical to write the Order to file. Thus, they have been hidden from the end user by right clicking and specifying “Hide Row.” The submit button was also painted to contain different text. As far as painting goes, I also modified the redirect so when the order is submitted, the user is taken to a confirmation page.

As far as the application itself, it is written over a separate table — the MAKEORDER table. Not only are these records written to the MAKEORDER file, but we have installed an external object, which can be written in either RPG or JAVA, that will run our business’ back end logic. The RPG/JAVA logic is solely up to you, however here is how we called our External Object, utilizing the *AFTERADD logic:

Your logic could do any of the following tasks: Remove items from the Shopping Cart File, Send confirmation E-mails, Update warehouse quantity, Create Order Detail Information, etc…

Once the user hits “Submit Order,” the record is written to the MAKEORDER file, our external logic calls our back end business logic, and the user is taken to a Confirmation Page:

This confirmation page consists of a servlet that has painted all of the fields out of it, and was just used for the m-Painter interface. It consists of basic text with a few very basic HTML links.

Related Posts:

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>