Eric van der Vlist wrote:
Probably not. Actions used for things such as adding repeated items will not be needed any longer, instances will only be uploaded if they don't have errors, ...
For adding repeated items, I would say that should remain the same, because you already typically use xforms:insert and xforms:delete, so it is declarative and in the XForms spirit.
For validation, it should be transparent. Whether there is a roundtrip to the server or not is an implementation detail. Maybe were are not transparent enough here, because we tell the user to check whether there are validation errors in the PFC. But this may just be a shortcoming of the current implementation (by the way, what about calling this the OPS XForms engine, in short? ;-).
Now when you are talking about actions, you may be right and wrong.
Today, storing a certain value in an "action" element has two purposes:
1. Work around the fact that the OPS XForms engine doesn't support events and actions.
2. Actually tell the server something.
For #1, once we implement at least a subset of events and actions, this use can mostly disappear.
For #2 however, I would imagine the use will stay. With client-side XForms, how would you communicate to the server the action to be performed if, say, like in the BizDoc application, you select either "Edit", "View XML" or "Delete" for a given document in a document list?
The actions have to be done server-side, because they involve accessing a database. I see two options: storing values in an "action" and "document-id" fields, or doing this through the URL. I don't think the second option is doable in XForms.
Now there may be a better way.
I am wondering if that wouldn't be a good thing (for a future release) to try to decouple the server side implementation from the XForms itself.
This does make sense, although I am not too sure of the implications.
This could include normalising a server side envelope that encapsulate actual instance documents and also providing the envelope and the actual instance document as two different inputs.
We could then write XPath expressions against the root of the actual instance that would be independent of the envelope.
That can be done right now by replacing "/form/document/root" by "//root". Maybe we should consider that a good practise even if it can have impacts on the performances?
In fact there should be no impact on performance if you write //root[1], if the XPath engine is decent. I even think there should not be any impact if you write //root, because the search for the following "root" elements in the sequence should be done lazily, and not happen if you only access the first element. I would guess the Saxon XPath implementation would do that kind of things.
As a BTW, I often use /*/blah instead of /root/blah, because there is always only one root element and we usually don't care much about its name. The drawback is that it may make the code a little less legible.
What do you think?
Are there other evolutions and/or good practises that could maximise the
portability of XForms forms designed to run on Presentation Server?
I think there is some good brainstorming and work to do to make server-side and client-side XForms implementations cohabit in OPS. The reasons we decided to use XForms in the first place included the fact that it is a standard (excuse me, "recommentation"), and in theory cross-platform and cross-browser. So I think this work has to start soon.
Another area to look at is the question of appeance. Client-side XForms probably require CSS, and it is probably good practice, for portability between server-side and client-side implementation, for server-side implementations to use CSS as much as possible.
Some experimentation will be useful to progress here.
Note that we can already use non-free client-side implementations today, like FormsPlayer, which are probably closer from implementing the whole 1.0 spec than Mozilla.
-Erik
------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ orbeon-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/orbeon-user
