Am Don, 2002-12-19 um 10.07 schrieb Konstantin Piroumian: > From: "Jakob Praher" <[EMAIL PROTECTED]> > > > hi Ivelin, > > hi all, > > > > for the last project I used a self-brewed, but kind-a grown, form > > handling mechanism. > > > > now I'm going to use Cocoon XMLForms, because the more people use it the > > better it gets ( instead of inventing the wheel again ) and I like its > > closeness towards w3c/xmlforms. > > Great! >
I'll go through your comments in detail. I hope to come up with a better design - with tight integration on w3c/xmlforms. Good that I posted, since I have overlooked the src attribute in the XForm spec. thanks. I am working on it and inform you. > Just a few comments on it. > > Basically, your idea is to be able to use external data references to use in > form controls, right? So, I'd like the syntax to be as close to W3C XForms > (http://www.w3c.org/MarkUp/Forms/) as possible (and where possible). > > There is a 'src' attribute used for linking to external sources: > http://www.w3.org/TR/2002/CR-xforms-20021112/slice3.html#structure-attrs-lin > k . > > Also see how the input controls are bound to the instance data using binding > expressions: > http://www.w3.org/TR/2002/CR-xforms-20021112/slice3.html#structure-bind-elem > ent > > > > > now to my idea: > > > > often you have data-source, which provides you with changeable data. > > > > take for instance countries and states (not very dynamic I agree, but > > for the sake of simplicity I will use this example). > > > > so you have xml-data, which can be "GENERATORED" by litteraly anything > > ( a file on the filesystem, ... ): > > > > A) the data > > > > <countries> > > <country id="at"> > > <name>Austria</name> > > > > <states> > > <state id="xy"><name></name></state> > > > > <...> > > </states> > > </country> > > </countries> > > > > > > and a xml form. The question is how to intermix the data with the form, > > in a very easy but powerful way. > > There are two ways to make this data avalable on an XMLForm: > 1. retrieve it on the server-side and then evaluate all expressions > where this data is referenced > 2. generate a special JavaScript on the server-side and then retrieve > the data on request, e.g. when user enters a country code manualy a request > can be sent to server to retrieve the name of the country (or a list of > countries). > > > > > B) The XFORM > > > > Now we have this wonderful xform document: > > > > <document xmlns:xf="..." xfdata=".:"> > > > > <xf:form id="..." > > > > > <selectOne ref="/country" > > > ... > > </selectOne> > > <selectOne ref="/state" > > > ... > > </selectOne> > > > > </xf:form> > > > > </document> > > > > > > writing xsp pages, or other generatos that generate the <xf:items> is > > one way, but I think this scenario is very frequently used and so it > > would be better to provide a more "integrated" framework. > > Yes, it's much better to extend the XMLForms transformer to perform this > task. > > > > > one proposal would be: > > > > <document> > > > > <xfdata:provider id="states" > > > > > <xfdata:source id="src-states" href="cocoon://data/provinces" /> > > Or > > <xf:instance id="country-list" src="cocoon://data/countries" /> > and then you can reference this data in your form controls as: > > See more on this: > http://www.w3.org/TR/2002/CR-xforms-20021112/slice3.html#structure-bind-elem > ent > > > > > <!-- > > > > raw - read after write means this value must be > > known prior to calculating the values. > > this can be done using the client side "change" event > > > > > > --> > > > > <!-- the dependency could also be stated directly in the xform ... --> > > <xfdata:dependency > > type="raw" > > name="country" > > form="offer" > > select="country" > > > > /> > > > > <!-- the key --> > > > > <xfdata:key > > name="states" > > match="countries/country[@id=$country]/states/state" > > use="@id" > > /> > > > > > > </xfdata:provider> > > > > .... > > > > <xf:form id="offer"> > > <xf:selectOne id="country" ref="/country"> > > > > </xf:selectOne> > > > > <xf:selectOne id="state" ref="/state"> > > <xfdata:choices use="states" > <!-- here use means a provider/key --> > > <!-- the dependency could go here too, so that proivders would be > > form independent --> > > > > <xf:caption xfdata:bind="name" /> > > <xf:value xfdata:bind="@id" /> > > > > </xfdata> > > </xf:selectOne> > > </xf:form> > > The above code looks very similar to a calculated binding expression in > XForms: > http://www.w3.org/TR/2002/CR-xforms-20021112/slice6.html#model-prop-calculat > e > > > > > > > to make this work, one has to write a custom translator, as xslt can't > > have global state that changes (variables are immutable). (except when > > using extension mechanisms). > > > > and my approach would be: > > > > 1) gather all the providers together in a list. > > 2) go through the xf:form and consume all xfdata:elements > > These are implementation details that can be decided as we agreed on the > syntax. > > > > > 3) write out different versions based on: > > > > -> client side javascript > > -> soap ? (+client side javascript :-) ) > > -> static ( that will be difficult ) > > > > > > does anybody have a cleverer way to do the above - what are your ideas? > > IMO, all the above can be implemented in the XMLForms transformer and XSLT > XForms stylesheet. > > Regards, > Konstantin > > > > > thanks in advance > > > > -- Jakob > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, email: [EMAIL PROTECTED] > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
