Eric van der Vlist wrote:
> The thing I don't like very much about this solution is probably > more aesthetic then technical... > > In my simple example, the XForms is written has it would have been > written for any other implementation (except for the need to > separate the model from the UI which isn't a bad practice anyway). > > In the BizDoc example, that's no longer the case since you had to > embed the actual instance document into a container (ie the root > element "form") together with the actions that are needed in the > client server communication between the browser and the server. > > The consequence of this adaptation is that your instance document > isn't any longer the document that you are editing and that you need > to carefully craft your pipelines (using xupdate in that case) to > embed and desembed the actual document into the instance manipulated > by the XForms. > > Is there a way to avoid that or is it a consequence of the > architecture?
I undertand the issue. The reality is that often, and this is probably independent from the client-side vs. server-side XForms question, you may need to submit data unrelated to the document being edited. The questions that come to mind are:
1. Can you avoid doing that at all?
2. If not, can you pass such information outside of the (main) instance?
3. And of course, is it really an issue to have an XML document embedded within another one.
For #1, a scenario is often to pass an action name, sometimes with parameters. For example, I select "View this document" on my summary page, so I want to communicate to the server that I want to view a document, but also which one. With xforms:setvalue, this is extremely easy an flexible, more so than, for example, having to create a different sumission URL with parameters by hand, which may not be possible with XForms 1.0.
For #2, you can use the action URI, which is not very convenient, and I am not sure if/how you can dynamically build it when submitting at submission time. Now if you could submit several XForms instances at a time with XForms, you would have your solution: one instance could contain the actual document to edit, another one could contain metadata related to the submission itself.
I have to say that #3 has not been an issue for me so far, because it is so easy to to embed your document into a larger instance on one hand, and to extract it from it on the other hand, with tools like XSLT, XPointer, XUpdate, or XInclude. Even with APIs like dom4j, it is easy to extract a document from a child element of a document. If you were using a different XForms engine, you could keep the same instance-with-metadata model, and easily extract your document as well. I agree that it would be nice not to have to do this.
So consequence of the architecture? At this point the answer appears to be yes. But this may not be the end of it.
-Erik
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/
_______________________________________________
orbeon-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/orbeon-user
