design issue: repeat

Hello,

here is another thing I wonder about:

What I want is a nice CRUD (create/read/update/delete) Xform for
arbitrary entities.
I implemented my version of it using two instances(list/entity) and a
switch with
1) a branch for a list, that is paged, i.e. a repeat with only 20
entities at a time.
    there are paging buttons for the next / previous 20 entries, that
load that list
    using a submission to replace the list instance.
2) a branch for a single instance, that displays input fields for each
attribute of the entity.
    this branch is used for the update and create functions.

my question comes up while implementing a delete function. I display a
"delete" button in each row
of the list (repeat). When I click on the button, the index is not
updated, so there is a chance, that the
delete button in row 4 will eventually trigger the deletion of the
entity in row 2, which is of course
a little off the way. I see no way to work around that problem, and
there remains a big question:
Why use a repeat in the first place. As I understand xforms repeats,
they offer a way to work on a list
by adding new entries (using insert actions), deleting entries (delete
action) and maybe change some
of the entries (setvalue). The xforms spex suggests, AFAIK, that the
whole instance, i.e. the complete
list afterwareds be send in a submission and be processed (here: be made
persistent).
Now this does not match with my approach, which is, I think, a rather
common way to handle that
kind of list management in web applications:
If you display a list and click on delete, you send a request and the
row is deleted. If you insert a new
entry, fill in the form and send the new entity to the back end. In
short: the list manipulations are executed
immediatly, instead of collecting all the shown data and at the end
process them as a big bunch.

There is one advantage doing the later version:
- the processing is much easier, since the back end does not have to
check, wether the original list was changed.
  this would be not a problem with update or inserts, since the data
comes with the submission and can just be
  stored in a database. But what about the deleted rows? The backend (if
it does not keep some state) does not
know, if there were rows in the list, that now (at the processing of the
manipulated submission) are not there
anymore, hence those rows could not be deleted, unless the backend
"knows"the old state of the list.

Using repeats is much more difficult here:
If you use them to submit the whole list, you face the problem I just
described. If you submit every change
in the repeat immediatly after / while doing the insert/delete action,
the list might loose its semantic sense:
for example the list could show sorted entries. if you insert a new row,
the whole list should be reloaded to
reflect the sorting. The same is true for filters, paging or other list
related standard features.
In short: what is the real sense of repeats? The fact that they are the
only way to implement lists in Xforms
because there is no xforms:for-each and they force me to handle row
entries indirectly (via the index in
cooperation with one selected row) for my use case is a real throw back.
"traditional" list handling in web applications is faster, direct and
thus even reduces a possible transactional
conflict, because there is no "bulk" manipulations, that later are
written to the database at once.

If I could set the index before submitting
inside the trigger, using the setindex() function, it could work. But
since I cannot feed that function with the
"current" row that is no option. I even think, that clicking on a button
inside a repeat row should automatically
set the index to that row. Erik, could you please check the Xforms spex
here? This might be a bug?

I now would choose to avoid the repeat module completely, but that is a
bad thing too, because I could
not use the ajax version of the Xform engine, since there is no
xforms:for-each and would have to build
the xforms from scratch for every request.

What should I do? How do you guys handle list processing?
:oliver
 

--
-----------------------
oliver charlet
software development

11-041 Olsztyn, Poland

[hidden email]
-----------------------




--
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
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Answering below another post that did not get any response:

 > my question comes up while implementing a delete function. I display
 > a "delete" button in each row of the list (repeat). When I click on
 > the button, the index is not updated, so there is a chance, that the
 > delete button in row 4 will eventually trigger the deletion of the
 > entity in row 2, which is of course a little off the way.

The statement above is in fact not correct: when the user clicks on a
button (trigger) within an xforms:repeat, the repeat index *will* be
updated to point to the row being acted upon prior to the DOMActivate
event being fired. We show this in the old BizDoc NG example (saying
"old" because in general it's better now to look at the new DMV Forms
example).

 > If you display a list and click on delete, you send a request and
 > the row is deleted. If you insert a new entry, fill in the form and
 > send the new entity to the back end. In short: the list
 > manipulations are executed immediatly, instead of collecting all the
 > shown data and at the end process them as a big bunch.

I think there is a misunderstanding here about what xforms:repeat and
xforms:trigger actually do:

o A button (trigger) within an xforms:repeat does not automatically do
   anything. You have to listen for events (DOMActivate) and perform
   actions for the button to actually do something.

o There is no requirement to perform operations on the list
   immediately with xforms:delete / xforms:insert.

o There is no requirement to submit the entire XForms instance upon
   which the repeat operates.

In short, there is absolutely nothing that prevents you to do what you
want to achieve with XForms.

We show how this is done with both the BizDoc NG example and the DMV
Forms example: upon pressing a "delete" button, the id of the element
being deleted is stored into a "request" instance, which is
submitted. The submission returns an updated list containing the
latest and greatest items to display.

 > In short: what is the real sense of repeats? The fact that they are
 > the only way to implement lists in Xforms because there is no
 > xforms:for-each and they force me to handle row entries indirectly
 > (via the index in cooperation with one selected row) for my use case
 > is a real throw back.  "traditional" list handling in web
 > applications is faster, direct and thus even reduces a possible
 > transactional conflict, because there is no "bulk" manipulations,
 > that later are written to the database at once.

The "real sense" of xforms:repeat is to do exactly what your
xforms:for-each would do. In other words, XForms does have an
xforms:for-each: it's just called xforms:repeat!

There is no "bulk" manipulation to write to the db at once, and there
is no particular difference with traditional list handling as you
describe it.

 > I now would choose to avoid the repeat module completely, but that
 > is a bad thing too, because I could not use the ajax version of the
 > Xform engine, since there is no xforms:for-each and would have to
 > build the xforms from scratch for every request.

It should be pointed out that even though the XForms 1.0 spec hints
otherwise, xforms:repeat on one hand and xforms:insert / xforms:delete
on the other hand are quite separate. In future versions of XForms, we
actually want to clearly separate these two things in the spec:

o xforms:repeat just repeats a group of controls.

o xforms:insert / xforms:delete just operate on an XForms instance.

Current XForms implementations, including the OPS XForms engine,
usually already interpret the spec this way. This means that to solve
your problem:

o You use xforms:repeat in your summary page to *display* the list of
   documents.

o You do *not* use xforms:insert / xforms:delete.

o You use an XForms submission with instance replacement to update the
   list. This ensures that your UI will be updated to be in sync with
   your server-side data.

I think that the above makes it clear that XForms allows you to do
exactly what you are trying to do, and this is great news!

I hope this helps,

-Erik



--
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
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws