Forum OpenACS Development: Re: xotcl core cr procs throw out assigned item_id and assign a new one, why?

My goal was to extend an Xowiki Form which has a preassigned id which is never used.

In the new_request and generate method the item_id is set to one value. In the after_submit method it is set to a different value. That's why my code didn't work since it assumed the assigned id in the hidden variable of the form would be used to create the new xowiki page.

I can probably write a workaround that references the old form value in after_submit method to compare the old item_id to the newly assigned one.

if you have to write a workaround, how can we improve or at least maintain teachability, understandability, maintainability?
Dave, the easiest thing is to subclass Form (e.g. xowiki::WikiForm) and define your own Form-class (this is the oo recommended way to extend a class). Then define your own method "new_data" (based on the definitions of WikiForm.new_data and Generic::Form.new_data; the latter.new_data does the "save_new"). There you have full control about the saving operations for new items.

As mentioned before, be aware that you have to care about the validity and security of the passed id, since one cannot trust on from-data.

Jim: i see you point, using the fresh item_id as a "poor men's transaction code". i would not rely on this without further checking. The the storage operations in the db are quite late for double-click prevention, and not particularly well suited for meaningful error messages concerning double-clicks.