View Composer is a Views-like module, built over a full OOP API strongly interfaces oriented (attempt to be as near as it can be from the SOLID principles).
Basically uses some well-known patterns and take strong design orientation to get rid of stupid problems:
Built over the OOX module ObjectStream interface and API as a backend, which makes configured backends re-usable from bundle to bundle
Built over the same module Formable API as a UX helper
Built over the XoXo module Storage backend for persistence (which can be proxied as entities)
Uses the Null Object pattern at normal runtime in order to avoid any WOSD or end-user ugly crashes
Object streams are backends, while the defined frontend interface is context agnostic and pragmatically render objects given by the stream using a formatter. The formatter is everything agnostic except the object it renders. The concept of bundles ties the lot configuration and handles persistence for the objects, and will allow you to place it anywhere in the site
Uses a somewhat random but working implementation of the decorator pattern in order to decorate the frontend display
An "update cart" form is placed on the product page just above the "add to cart" form if the user already has the product in his/her cart. Thus there exists both the ability to change the existing items(s) in the cart as well as add new item.
Currently this module only works with single products and not product kits.
If you're a coder, your feed back would be greatly appreciated.
I am using hook_nodeapi with $op='view' to then call the update form. The update form code is pretty much a copy of similar code seen in the uc_cart, uc_product and uc_attributes modules. There are some additional comments in the code itself.
I am not if this is the best route to go. Maybe this is just a proof of concept.
While Drupal provides capabilities for commentng for both anonymous and authenicated users, it provides no easy way for authenticated users to post comments anonymously without having to manually l