W3C home > Mailing lists > Public > www-forms-editor@w3.org > February 2003

Add a reload action to xf:model

From: Mark Birbeck <Mark.Birbeck@x-port.net>
Date: Mon, 17 Feb 2003 21:55:48 -0000
Message-ID: <E3ED00A7C285EE408679DE2A26D1C7818FFE92@S007.x-port.net>
To: "'www-forms-editor@w3.org'" <www-forms-editor@w3.org>

Dear all,

ABSTRACT
In systems where many users update the same data source it is desirable to
reflect user changes to data back to the database as quickly as possible.
This requires that instance data can be reloaded from the same location that
it was originally loaded from.

Whilst this can be achieved through xf:submission, it requires the
configuration of parameters that must be manually kept in line with other
data.


INTRODUCTION
We find that the following is a common pattern:

  <xf:model id="mdlActivityList">
    <xf:instance id="list" src="/data/schema/Activity.xml" />
    <xf:submission
     id="siActivityList_Reload"
     method="get"
     replace="instance"
     ref="/SomeNodeThatDoesNotExist"
     action="/data/schema/Activity.xml"
    />
    <xf:message
     level="modal"
     ev:event="xforms-link-exception"
    >
      Could not load Activity data
    </xf:message>
  </xf:model>

As you can see there is an xf:submission statement that is being used purely
to achieve a 'reload' of the instance data. There are a number of problems
with it though:

1. The @action is always set to the same as xf:instance/@src which means
that it must always be kept in line - adding administrative headache.

2. We are trying to do a 'replace instance' but we can't actually refer to
the instance to be replaced (because if we do then the data will become
serialised as parameters to the HTTP GET)..

3. We are relying on our knowledge of the way that instance data is loaded,
i.e., using 'HTTP GET'. If this were ever not to be guaranteed then the
@method property would need to change. This seems an unnecessary limitation.


EXAMPLE
A common use of the artificial reload we created above is to have a list of
items that may be edited, and to have any changes to that list to be
immediately reflected on a server, rather than holding changes and
submitting them all in one go. This is often required when a number of
people are working on the same data source.

For example, the instructions for deleting a record from the above list are
as follows:

  <xf:trigger>
    <xf:label>Delete</xf:label>
    <xf:action ev:event="xforms-activate">
      <xf:dispatch target="mdlActivity" name="evActivity_Copy"/>
      <xf:send submission="siActivity_Delete"/>
      <xf:send submission="siActivityList_Reload"/>
      <xf:message level="modal">The item has been deleted</xf:message>
    </xf:action>
  </xf:trigger>

This copies the currently selected item from the list model to a temporary
model, where it is used as the parameter for a delete instruction. If the
record is successfully deleted we want to reload the list so that the entry
is no longer present, which also retrieves changes made by other users on
the system.


PROPOSAL
I would like to suggest therefore, that a 'reload' action is added, that
re-executes the loading of initial instance data. This is not the same as
'reset', which has the effect of abandoning a series of changes to the
instance data and then reverting to the initially loaded instance data.

Adding a 'reload' action would require that there is a further event between
'xforms-model-construct' (4.2.1) and 'xforms-model-initialize' (4.2.2),
possibly called 'xforms-model-load'. This would execute steps 2 and 3 from
'xforms-model-construct':

  xforms-model-construct
    1. load schemas
    2. fire xforms-model-load

  xforms-model-load
    1. load instance data
    2. fire xforms-model-initialize

  xforms-model-initialize
    as now

This allows the reload sequence to begin without unnecessarily reloading the
schemas.

The action could be defined as follows:

  <xf:reload model="mdlActivityList" />

[It may be possible to add the 'reload' action to xf:instance, but since
there is very little on xf:instance in the spec, I assumed it was better to
suggest that it be put on xf:model.]


CONCLUSION
Being able to easily retrieve updated data for an instance from the original
location would be useful in systems where many users are connected to the
same database and changes are occurring frequently. Whilst this can be
achieved through xf:submission, it requires the configuration of parameters
that must be manually kept in line with other data.


Regards,

Mark



Mark Birbeck
Co-author Professional XML and
Professional XML Meta Data,
both by Wrox Press

Download our XForms processor for IE
from http://www.FormsPlayer.com/

Managing Director
x-port.net Ltd.
4 Pear Tree Court
London
EC1R 0DS

E: Mark.Birbeck@x-port.net
W: www.x-port.net
T: +44 (20) 7689 9232
Received on Monday, 17 February 2003 16:59:31 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 10 June 2009 18:12:12 GMT