W3C home > Mailing lists > Public > www-forms@w3.org > November 2006

Re: repeats

From: Jason <jeacott@hardlight.com.au>
Date: Tue, 14 Nov 2006 08:43:18 +1030
Message-ID: <4558EDFE.2090506@hardlight.com.au>
To: mark.birbeck@x-port.net
CC: Erik Bruchez <ebruchez@orbeon.com>, www-forms@w3.org

Yep - this is Exactly my point, and I totally agree that a globally 
useful bind function would be a far better solution than doubling up on 
attribute names.

Cheers
Jason.


Mark Birbeck wrote:
> 
> Erik,
> 
> I think Jason's point is very good, and it is exactly the same reason
> I have been trying to get a bind function into XForms for ages.
> 
> His argument is basically that having that 'extra level of
> indirection' is a bonus because it allows the data to move without the
> UI having to change. I would totally agree with this, and can provide
> a large number of forms that we have devised where we have created
> generic 'patterns' where the UI sits atop a set of bind statements,
> and then those bind statements map to specific data. This is crucial
> for 'reuse'.
> 
> For example, when creating a form that makes a request to a server,
> and then navigates the list of items returned, with 'next' and
> 'previous', etc., the mark-up is almost identical each time, with the
> only difference being the XPath expressions to access the data.
> Instead of having to edit XPath expressions in the UI, we can use bind
> statements to create a UI that navigates a 'recordset', and then just
> change the binds to suit different data.
> 
> XForms needs far more of this kind of stuff if it is to be reusable;
> at the moment my guess is that many forms are hand-crafted,
> artisan-style, but there is no reason that people shouldn't be able to
> take my 'recordset' pattern and just drop it into their forms, and
> then simply tweak the bind statements accordingly for their data.
> 
> Regards,
> 
> Mark
> 
> 
> On 13/11/06, Erik Bruchez <ebruchez@orbeon.com> wrote:
>>
>> Jason,
>>
>>  > really?
>>
>>  > I haven't checked the detail of the new insert attributes - are you
>>  > seriously saying that you cannot use a bind as an origin or context?
>>
>> The @origin and @context attributes are XPath expressions.
>>
>>  > If thats the case then its just another nail in the whole bind
>>  > coffin I think - w3c folk - What is the point of creating binds if
>>  > you cant use them anywhere?
>>
>> XForms uses different attribute names to refer to binds (@bind)
>> vs. XPath expressions (@ref, @nodeset, @context, @origin). From that
>> you can infer that @context and @origin must support either XPath, or
>> bind ids. Currently, it's the former. What you would probably want is
>> something like @context-bind and @origin-bind, but these attributes
>> are currently not defined in XForms 1.1.
>>
>> This is good feedback for the working group though: I am not sure
>> whether we have considered using binds for the functionality or
>> @context or @origin so far.
>>
>>  > please consider this when designing this stuff because xforms is
>>  > threatening to become a nightmare of xpath to manage.
>>
>> Well, that's a open debate. You want to use binds everywhere, but I
>> usually don't use them much. So I for one don't have any problem at
>> all writing:
>>
>>    @origin="instance('my-template')"
>>
>> That's simple and clear enough for me (but that's just me).
>>
>>  > Just think how painful it would be to add/remove/change any data
>>  > structure in any big complex array of forms if they are just
>>  > completely littered with xpath.
>>
>> That's probably subjective. Someone could argue that you are littering
>> your form with binds ;-) Binds add an additional indirection, which
>> has benefits but also drawbacks - like the fact that you add to the
>> existing XPath "space" a new space of bind ids.
>>
>> (Digression: This reminds me of things like Java ant files: people
>> always tend to write things like:
>>
>>    <property name="war.lib" value="${war.inf}/lib"/>
>>
>> Somebody could argue that sure, that's a valuable indirection, just in
>> case someday you want to change where the WAR lib directory is, or
>> where the WEB-INF directory is. The truth is that you are never going
>> to move it, and that the indirection is fairly pointless: you will be
>> as clear writing WEB-INF/lib instead of ${war.inf}/lib.
>>
>> This not to say that binds are useless, but that they may, in some
>> circumstances, be just pointless indirections. End of philosophical
>> digression.)
>>
>> -Erik
>>
>> -- 
>> Orbeon Forms - XForms Everywhere
>> http://www.orbeon.com/blog/
>>
>>
>>
> 
> 
Received on Monday, 13 November 2006 22:13:55 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 10 March 2012 06:22:08 GMT