- Nov (Monday).
- Nov (Tuesday).
Rewrote net.data category display functions to use proper parameter-passing. Began writing simple product-display page proddisp.d2w, which serves as the basis for the Danly "shopping experience" item selection page(s). Creating data by-hand via e250.ibsentg.com/ncadmin interface, including actual item information with attributes, to test proddisp.d2w.Continued to do battle with DB2/Commerce Suite -- now it appears that even just stopping a running commerce suite instance can corrupt something, so that it cannot be started again. Oy!
- Nov (Wednesday).
Wrote test Javascript page nrad.html as proof-of-concept of cascading menus. The idea is that as the user makes a selection from one menu, it adjusts the list of choices in the next menu, and so on down the chain. Abstracted both pull-down menus and radio button sets into a "chooser" object, so we can mix them together as in the example. (But radio button lists should only be used when we know that the radio choices exist for all combinations of preceding menus!)In the process, learned that Netscape has trouble with dynamically created pull-down menus -- if you use the Option() constructor to create menu entries, then you have to call history.go(0) to tell Netscape to refresh its view of the screen (otherwise the created menus look really, really, ugly). But doing the refresh means reloading the page from the server, which in the case of net.data generated pages, means another trip through net.data, DB2, etc. etc.! And avoiding that was the whole point of making these menus dynamically generated (by the browser) in the first place.
So the solution was to generate all of the menus with the "fullest" possible set of choices, and then to dynamically rewrite their text and value members with the actual choices as the user works "down" through the menus. If a menu has 8 slots and only 4 are used, the remaining 4 are set to blanks. This means that on occasion the menu, when clicked, will appear longer than it should -- but the inconvenience is small compared to reloading from the server. (Try ordering a green T-shirt from the example; silk is not a choice, but there's a blank line at the bottom of the menu.)
Began adapting proddisp.d2w to actually write all the appropriate javascript to produce a set of menus (like above) from the product info in the database. The really nice thing about this is that 90% of the "shopping experience" pages can all be generated directly by by one .d2w script -- everything will flow from the data. We will have to have some way to (a) indicate if an attribute name should appear as a menu or a set of radio buttons, and (b) what order the attribute names should appear in -- but those can probably be set up in custom/reserved fields in the database.
Introduced myself to "Padma" at SFC, the person who is taking over for Quinn since Quinn left. Phone 415 255 0200, e-mail ppadmavathy@ibs.com.
- December (Friday).
Helping Steve get up to speed on working with Net.Data d2w "macro" files. Since he didn't seem eager to learn vi (can't imagine why <g>), I went looking for some dimly-remembered tools that let you edit a file under Windows, while auto-magically loading/saving it via FTP on the remote server.Found a few under http://www.dmoz.org/Computers/Software/Internet/Clients/FTP/; in particular, CoffeeCup looks good.
Meanwhile, back to programming the Danly shopper experience... generating long complicated strings of JavaScript inside .d2w files is somewhat of a pain, especially if you want to be able to read the generated HTML/JS. Found the easiest way is to build the JS lines a piece at a time as a string, and then output them, with DTW_REMOVE_WS set to "YES". Even then, I found it easier to get the various results from the @dtw_tb_rgetv() calls, stuff them in individual strings, and then assemble the results from the strings. Yecch! But it works cleanly. (Appears that trying to call @ functions inside a string can get confusing to the interpreter or the coder or both!)