On Tue, 2003-10-28 at 10:40, joern turner wrote: > Bruno Dumon wrote: > > On Mon, 2003-10-27 at 22:24, joern turner wrote: > > > >>Oleg Dulin wrote: > > > > <snip/> > > > >>>The remainder is tricky. I accomplished this by setting up an internal > >>>pipeline that uses RequestGenerator to create an XSL transform called > >>>"update.xsl" that applies the changes to the original document. To know > >>>which form values go to which places in the original document I used > >>>xpaths of the original elements and attributes as names for input > >>>fields. So, an XSL can be generated that applies the changes to the > >>>original doc and wraps it in something that SOurceWritingTransformer can > >>>understand. > >> > >>Chiba has a similar concept but without exposing xpathes of the instance > >>(for security reasons). it uses a mapping between xpathes and internally > >>generated ids. > > > > > > You're pointing out two things here already people might not like about > > Chiba: > > - it assumes stateful operation (most of Woody also works stateless, > > thus without keeping any state on the server, which can be useful in > > some cases). > ok, that's right. Chiba uses sessions. but that has nothing to do with > the XForms functionality. we can also decide to move it to a stateless > model if this might turn out to be more adequate. this is not an issue > of the XForms engine but of the embedding application. > > but anyway, thanks for the point - maybe we should evaluate the idea to > move to a stateless model.
Note that I didn't say stateless is better, in some cases it is (simple forms combined with high traffic) and in others not. > > > - it uses meaningless id's as request parameter names > well you don't have to. you *can* use e.g. the xpathes for parameter > names but we considered this a bit too much transparency. Agreed, and xpath expressions encoded as request parameter names look very ugly. Anyhow, the point is that Woody doesn't have this problem at all. > this should be > hidden from a user (even if a developer might like to see it). you just > have the choice to expose as parameter name whatever you like by > implementing an interface. > > but for us - we've been there and tried working with the xpathes for > quite a while - security is obviously one reason to dislike it and it > also bloats the output code with very long xpathes if you have a deeply > nested instance data structure. this significantly increases the > document size if you're editing medium size xml documents. -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
