Colin O'Brien wrote:
> please excuse me jumping into this discussion. I've only been studying > Presentation Server for less than a week.
No need to excuse yourself. This is a public forum, and all ideas, especially good ones, are welcome ;-)
> For most of January I was looking at cocoon and related > technologies, until a post on the cocoon list led me here ;-) I > immediately liked that you were using XForms, amongst other things,
I'm glad to see that you like the XForms approach. I think it is very important, and that starting to support XForms server-side is pretty much the only migration path towards XForms at this point, unless you operate in a controlled environment where you can control browser versions and/or plugins.
> though I was concerned that it was not only a subset, but some > things that XForms did seemed to be left in XSLT Templates (I hope I > am getting this right, I've only read the tutorial, and not all the > documentation so far, and then it's a while since I was reading the > XForms spec).
I am not sure of how I should understand your statement here. We do implement subset of XForms, as documented here:
http://www.orbeon.com/ois/doc/reference-xforms-compliance
But there is more to web applications / web sites than just XForms, which is why OPS provides not only XForms but page flow, XML pipelines with XPL, components that you use used in XML pipelines to process XML documents, etc.
> I did some prototyping last year on round-tripping XForms to the > browser and back, so I know this isn't easy. It seems that your use > of XForms is only as a data model, and all the presentation is in > the template (presentation is the wrong word, I mean the controls - > I always look for layout and looks in CSS)
We use XForms pretty much the way it was intended to be used, except the don't implement (yet) events and actions, and a few other things.
But we do support the XForms model and instance, and most of the XForms controls.
The controls can be simply embedded in (X)HTML, which is the way they were intended to be used in the first place, but for more flexibility, you can generate the XHTML+XForms with XSLT templates. Think of XSLT here as a (nice) replacement for JSP.
Because with a server-side implementation, you must in the end send HTML+CSS to the web browser, the conversion of XForms controls to HTML+CSS is done server-side with XSLT templates as well.
> And I have to say I liked the use of the XSD as part of the > validation.
This is BTW part of the XForms spec. Here again we only implement a subset, but we plan to improve this.
> But if you want to be able to build a single XForms document
Not sure what you mean by "XForms document". An XForms instance? Or for example an XHTML document with embedded XForms elements?
> and have it go to either the client or your own server-side > round-tripping capabilities depending on the client's capabilities, > then the XForms has to be complete, in terms of achieving what you > want on the client - data model, controls, presets
Not sure what you mean by "data model" or "presets".
But you can still support only a subset of XForms that you code against and support this way the server-side OPS XForms engine and client-side implementations as well. As discussed ealier in this thread, we haven't made the step to support client-side implementations in harmony with the server-side implementation yet. More on this below.
> (though one would like to be able to merge them from a database > table), validation, and so on. It would seem the transition step is > that building a full-spec XForms document should not break anything > in Presentation Server (which is hopefully true already)
OPS supports a subset of XForms. So you better code against that subset if you are using the OPS XForms engine. If you are just serving XHTML+XForms to a web browser, then yes, of course, go ahead and serve full XForms 1.0: OPS can serve any XML document you want.
I think ideally, OPS should support of course more of the XForms 1.0 spec, to get as close to a conformant implementation, or to simply be a conformant implementation if possible.
But whatever the progress of the server-side implementation, OPS should support and document the use of client-side engines. This means things like:
o If I receive a request from a browser which claims supports XForms or that we know does support XForms, so for that particular request, we must not convert XForms controls server-side, but send them directly to the client.
o Also, if such a browser submits an XForms instance, I must recognize it and perform the adequate processing in the PFC, and not decode the XForms instance as encoded by the server-side engine.
There is probably more to it.
-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
