Edit Cart Item feature

[dreamingmind]

see issue #244 updateQuantity()

The source url could be included in the source form (and stored in Supplement) to simplify navigation back to the edit page.

This could make the edit feature a method on the PurchaseProduct base class which would be simpler than requiring concrete versions. But it would increase the design requirements for the forms used in the purchase process.

[dreamingmind]

A bit of a snag. I placed the url for 'catalogs/pname/purchase' in an edit_path field in the Supplement array, pretty much as planned. It worked fine... then later, when I was implementing the actual editing feature, I found I needed to use a different catalogs method to render the pname/purchase page.

Since I now had the same form on a different url, the edit_path field now had a different value.

Since I hadn't yet implemented the actual editing of a record, the button on the form now created a new record from the same form and the edit_path in the Supplement record was an unexpected pattern. So these new items were not editable.

Possibly, all I need to do is hook up the true editing processes and prevent the creation of new items from what is intended to be an edit page.

[dreamingmind]

It's hard to keep in mind that cart item editing is not a fixed process built into the cart system.

There is no requirement that a kind of product allows editing beyond the qty change and removal available in the cart ui.

But if a kind of product does allow editing, the feature is coordinated set of tools, unique to that product type.

The pieces involved:

• the concrete product helper will have an editItemTool($id) method that creates the link that will take the user to the item editing page
• In the bindery site, the CartItem record has a Supplement association which contains all the original data from the form used to place the item in the cart. This Supplement data is used to repopulate the item edit form.
• In addition to the Supplement data, the method targeted by the editItemTool() link may require other data for it's operation. In Bindery, custom and generic products require a string describing the product category to guide selection and rendering of the proper form. This datum is not necessary part of the originally submitted form, so it had to be inserted as an extra value just to support the cart editing feature for these products.

None of this is a fix or required part of the Cart system, nor are the details the only way an edit feature can work.

The only fixed part of the system's edit feature is the existence of a CartItem record and a method to supply the 'edit' link (or null if editing is not allowed).