Reset action in XForms not implemented (need some guidance to implement it)

Hi,

I noticed that org.orbeon.oxf.xforms.XFormsModel.doReset(PropertyContext) isn't fully implemented., i.e. the instances aren't reset. I was wondering why this wasn't implemented.

A naive implementation would be to 'clone' all mutable instances on xforms-ready by doing this in XFormsModel.doAfterReady. And restoring those copied (mutable) instances in XFormsModel.doReset by calling XFormsModel.handleUpdateInstance. An optimization could be to only copy the instances if the form has an xf:reset action in it, but this optimalization breaks if somebody dispatches an xforms-reset event using a dispatch action (the event name could be dynamic). If this feature isn't implemented for performance/memory reasons, we could maybe add an attribute on model to prevent the clone of the mutable instances.

Could you please give me some information about if this implementation is correct, an/or how you want it be implemented.

--
Regards,

Nick Van den Bleeken


--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
OW2 mailing lists service home page: http://www.ow2.org/wws

Nick,

I think it wasn't ever implemented because we always had other ways to
reset a form, like loading back an initial instance. That's how Form
Runner implements its "Clear" function, for example.

I think it's right to do it in XFormsModel.doAfterReady(). Statically,
in XFormsStaticState, we could detect the presence of any xforms:reset
action, and even static xforms-reset events. To handle the case of an
event name created dynamically, a hint would be needed.

Now here is a thing: we already have a notion of "initial client
state" to handle browser back. In XFormsServer.java, look for
XFormsConstants.XXFORMS_INITIAL_DYNAMIC_STATE_QNAME. This contains a
UUID sent by the client, which is a reference to the initial dynamic
state. That should contain the original instances already! The good
news is that then you wouldn't need xforms:reset detection etc.

So the trick would now be in doAfterReady() to find that UUID. I don't
think it's readily accessible right now other than from the client, so
we should store it into the dynamic state. Then you can retrieve the
full dynamic state, deserialize the instances, and set them back on
the respective models.

There might be a trick with local instances within XBL components...
Should those be restored too, and if so how? Or will they simply be
rebuilt as the controls are refreshed to match the new top-level
instances? Something to check at some point!

-Erik

On Wed, Apr 7, 2010 at 4:53 AM, Nick Van den Bleeken <[hidden email]> wrote:

--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
OW2 mailing lists service home page: http://www.ow2.org/wws