26. December (Tuesday). 

    Executing multiple Websphere commands
    "Registering" a new (to the website) user turns out to involve, in the Danly business model, multiple websphere commands:

    • Register a new user, supplying contact info (RegisterNew)
    • Add shipping information (AddressAdd)
    • Add billing information (AddressAdd)

    The websphere "ExecCmds" command should, according to the doc, allow us to run all of these commands, and chain to a "final" URL (in our case, the ExecMacro "home.d2w" macro).

    Surprise -- it doesn't.  Specifically, when I use the "in_0_url" parameter (or anything like it) and set it to either "/X" or "/" (as shown in the examples in the documentation and the downloadable FoodMart sample code respectively), why it just tries to execute one command and then go straight to a page called /X (or to the root page, again respectively).

    So... instead, I've used a pop-up window to "chain" through multiple commands.  The first page is a long form that gathers all the new-user-registration info.  On pressing the submit button, it executes the RegisterNew command to actually create the new user -- but with a TARGET of a newly opened pop-up window.  The URL argument for RegisterNew is for a tiny page that plucks out the info it needs for the shipping address (from the parent, "opener" page), and executes AddressAdd.  This in turn chains to another tiny page, still in the popped-up window, that plucks out the info it needs for the billing address, submits itself to another AddressAdd, and so on.  Finally the last page just tells the opener page to go to the site home page, and closes itself (the pop-up window).

    This actually works quite well and very fast.  The best part is using javascript to pluck the info out of the fields in the opener page and stuffing them into hidden fields in the tiny page -- this avoids all the nightmares of trying to pass the field data from page to page to page.

    One implication of this approach -- because certain of the websphere commands (like RegisterNew) want to use https: instead of http: for security reasons, it is infinitely easier to just make all of the pages use https.  This makes it important to have the very first link in to the home page specify https as well.

    In the meantime, I have an open support call to IBM tech support to find out why ExecCmds does not work as advertised, and will post that here and on my Websphere resources page if we ever get an answer.

    Mall-level and error macros
    Many websphere commands, when they fail, decide to go to specific macro pages that are included with websphere.  Naturally, this completely breaks the whole look-and-feel of the Danly site.

    In ncadmin, it is theoretically possible to set the macro values for some of the commands (tasks, really) to gain back control over the interface.  However, in some cases, this does not work!  More precisely, it appears that somehow the INCLUDE_PATH information does not get set correctly for these "error" macro pages, and websphere cannot find the page that I've tried to set to override the default page.

    Since I've already broken the websphere mold that "a store" = "an interface", I've chosen to do it yet again for the error pages.  The directory containing these default pages is: /opt/WebSphere/CommerceSuite/macro/en_US/base.  In there I've created subdirectories that match the store-level interface names (e.g. icharles, idanly, etc.)

    To give a specific example... if a user tries to register an id that is already taken, the Websphere RegisterNew command invokes the "base" macro err_reg.d2w.  I've renamed this to err_reg.inc, and written the replacement err_reg.d2w:

       %if (idn != "")
          %include "$(idn)/err_reg.d2w"
       %else
          %include "err_reg.inc"
       %endif
    

    Thus, if idn is defined, websphere will load the named idn directory's err_reg.d2w, otherwise it loads the default page, and all is well.  In the case of this example, the new err_reg.d2w just complains (in the pop-up window) about trying to register a duplicate id, and then is closed.  If this were not happening in an ephemeral pop-up window, it's not clear if we could do any significant useful stuff from here (is the INCLUDE_PATH correct?).

27. December (Wednesday). 

    Spiffy Hierarchical Menus
    Webreference.com has a really spiffy set of DHTML hierarchical menus at http://www.webreference.com/dhtml/hiermenus.  I'm using these to make the "Mr Phelps, you are shopping for Mission Impossible" link display the list of possible ship-to "site" addresses in a nice way (much more elegant than a pull-down menu).

    The only hitch so far is that the "onLoad" handler from the <BODY> tag must be moved to the end of the startIt() function in menus.js, but that's a small price to pay.  Each Danly page now defines a javascript function onLoad_handler(), which is called by startIt() in menus.js, and in turn calls whatever functions (such as MM_all()) would normally have been called from the <BODY onLoad="..."> tag.

    The menus could use some color adjustments to better fit the look and feel of the site; detailed instructions for the parameters for each menu are at http://www.webreference.com/dhtml/hiermenus/instructions/noframes/step3.html.

    ODBC
    I may end up implementing the Danly "order status" link as a separate program that does an ODBC query to the HFA database at Danly.  If so, there's a nice(?) ODBC package for Python at http://www.lemburg.com/files/python/mxODBC.html.

29. December (Friday). 

    ExecCmds, Reprise
    IBM got back to me with an apparent solution to the (bad doc on the) ExecCmds problem.  I've detailed it on my websphere resources page. 

    I had to restructure the new user registration for other reasons anyway, so I've used ExecCmds this time (successfully).  Although I kept the old page-chaining code in a subdir OLDNEWUSER, and I still use the pop-up page for handling error conditions from the commercesuite RegisterNew command.

---