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

Re: repeats

From: Jason <jeacott@hardlight.com.au>
Date: Fri, 03 Nov 2006 20:19:06 +1030
Message-ID: <454B1092.5000902@hardlight.com.au>
To: John Boyer <boyerj@ca.ibm.com>, www-forms <www-forms@w3.org>

Thank for responding John, but
what was wrong with the recommendation version? seems to work beautifully.

the thing is that I want to insert - not just append.
I want to be able to:
<xforms:insert bind="bind_1" at="index('repeat_1')" position="after"/>

and have it add a new row even if there isn't one. The way the 
implementation I've been using works is that it copies the last node of 
the original data. I've been using this in conjunction with the familiar
  hack in order to start out with a blank slate:
>          <xf:action ev:event="xforms-ready">
> <!-- delete the item ONLY if there is one and its description is empty. thsi should be enough to indicate we havent loaded an already built form. -->
>            <xf:delete bind="fditem" at="if((count(instance('formd')/item)=1) and (instance('form')/item/@description=''),last(),0)" />
>          </xf:action> 


the context option for v 1.1 doesnt seem to help at all:

This attribute is ignored if the bind attribute is provided.
(I need a bind dont I?)

If the context attribute is not given, then the default insert context 
is the in-scope evaluation context. Otherwise, the XPath expression is 
evaluated using the in-scope evaluation context, and the first node rule 
is applied to obtain the insert context.

The insert action is terminated with no effect if the insert context is 
the empty node-set or if the context attribute is not given and the Node 
Set Binding node-set is empty.
(Wont it always be the empty nodeset if I've removed them all?)

AM I right in thinking that the only way to buld an xform of this type 
is to alway shave a complete blank copy of the model, or on 
xforms-ready, copy the entire instance to a new instance somewhere  and 
then use the origin option in all your binds? wasnt that kind of hwat is 
happening in the background in my old implementation anyway?

I really must be missing something. I dont understand how this works at all.



Thanks
Jason.





John Boyer wrote:
> 
> Yes, I can explain it.
> 
> When the homogeneous collection is empty, there exists no last node of 
> the homogeneous collection to copy for the insertion, and there is no 
> place to insert the node even if you had one.
> 
> Using pure XForms 1.0, my paper in XML 2005 describes a repeat 
> methodology that will work for you.  Please see the subsection at this 
> link: 
>  http://www.idealliance.org/proceedings/xml05/ship/74/XFormsAndXFDL_Boyer.HTML#d0e1785 
> 
> 
> In XForms 1.1, we have improved the situation by adding the context and 
> origin attributes to insert.  A number of implementers support these 
> attributes already.
> 
> The origin attribute is able to indicate the prototypical node to be 
> used for insertion, so the homogeneous collection can be empty because 
> the origin node need not come from the homogeneous collection.  The 
> context attribute allows you to indicate the parent of the homogeneous 
> collection, so if the collection is empty, then you still know the 
> element into which the origin node should be duplicated.
> 
> Best regards,
> John M. Boyer, Ph.D.
> STSM: Workplace Forms Architect and Researcher
> Co-Chair, W3C Forms Working Group
> Workplace, Portal and Collaboration Software
> IBM Victoria Software Lab
> E-Mail: boyerj@ca.ibm.com  http://www.ibm.com/software/
> 
> Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
> 
> 
> 
> 
> *Jason <jeacott@hardlight.com.au>*
> Sent by: www-forms-request@w3.org
> 
> 11/03/2006 12:08 AM
> Please respond to
> jeacott@hardlight.com.au
> 
> 
> 	
> To
> 	Lee Standen <nom@standen.id.au>
> cc
> 	www-forms <www-forms@w3.org>
> Subject
> 	Re: repeats
> 
> 
> 	
> 
> 
> 
> 
> 
> 
> ok - sorry.
>                 it seemed that you were focusing on the repeat behaviour 
> over the insert.
> 
> perhaps there is an xpath statement that can be placed in the at
> attribute that will return a node if one exists or false or 'nan' if one
> doesn't (would be weird mixing types like that). that would fix it, but
> it seems like extra work that would in almost all cases be required and
> for no reason I yet see.
> 
> can anyone explain why this rule exists?
> "The homogeneous collection to be updated is determined by evaluating
> the Node Set Binding. If the collection is empty, the insert action
> has no effect."
> 
> this makes sense to me if there is no node to begin with (and/or no
> binding for the lazy case) because obviously you dont have anything to
> duplicate if thats the case. But here I just don't get it. why make
> insert harder to use by requiring a special case to add a new node if
> they've all been removed?
> 
> 
> 
> Lee Standen wrote:
>  >
>  > No, I didn't miss the point, that's what the specification says it
>  > should do.
>  >
>  > See my other post, for what should be a solution...again I don't know if
>  > it works with any or all implementations.
>  >
>  >
>  >
>  > Jason wrote:
>  >> Hi Lee,
>  >>     I think you've missed my point.
>  >> Insert now only seems to work if you actually have some data.
>  >> if you start with data - remove it all with <delete... at.../>
>  >> then <xforms:insert bind="bind_1" at="index('repeat_1')"
>  >> position="after"/> no longer does anything at all.
>  >>
>  >> I've tried chiba, the firefox extension, and formsplayer and they all
>  >> behave this way.
>  >>
>  >>
>  >>
>  >> Lee Standen wrote:
>  >>>
>  >>> Yep, insert works by duplicating the previous set of nodes, which you
>  >>> can then use <xf:setvalue> to clear as necessary.
>  >>>
>  >>> There was a trick somewhere to actually have a 'template' to pull the
>  >>> new set of records from...I'll try and find it.
>  >>>
>  >>> Jason wrote:
>  >>>>
>  >>>> Hi all, Today I decided it was time to upgrade the version of chiba
>  >>>> I've been using for my xforms only to find that its behaviour has
>  >>>> changed. I checked a few other implementations and they all seem to
>  >>>> agree on this point, so I'm totally confused.
>  >>>>
>  >>>> up until now I've been using a trigger with something like:
>  >>>>  <xforms:insert bind="bind_1" at="index('repeat_1')" 
> position="after"/>
>  >>>>
>  >>>> in order to allow form users to add items to lists. BUT if they
>  >>>> remove all the items from the list then this no longer works and I
>  >>>> apparently need a completely different button to get the first item
>  >>>> on the list again. Is this true? My existing copy of chiba just
>  >>>> inserts, even if there are currently no items in the list. how is
>  >>>> this supposed to work? how have people built real life forms to cope
>  >>>> with this odd behaviour(imho)
>  >>>> I've had another look at the w3c position for xforms 1.0 and it
>  >>>> seems to suggest that this behaviour is designed (unless the
>  >>>> "homogeneous collection" is actually meant to mean the collection
>  >>>> that exists at form startup including any implied nodes from binding
>  >>>> lazily? )
>  >>>>
>  >>>> ref: http://www.w3.org/TR/xforms/slice9.html#action-insert
>  >>>> The homogeneous collection to be updated is determined by evaluating
>  >>>> the Node Set Binding. If the collection is empty, the insert action
>  >>>> has no effect.
>  >>>> The rules for selecting the index are as follows:
>  >>>> b) If the result is NaN, the insert appends to the end of the 
> node-set.
>  >>>>
>  >>>> c) If the resulting index is outside the valid range of the
>  >>>> node-set, it is replaced with either 1 or the size of the node-set,
>  >>>> whichever is closer.
>  >>>>
>  >>>> so how should a shopping cart for example actually be built?
>  >>>> I want:
>  >>>> add item
>  >>>> remove item
>  >>>> checkout
>  >>>>
>  >>>> I dont want an append item for the case that there are none items,
>  >>>> and I really dont want to have to specially bother with the zero
>  >>>> case (how is this done anyway?).
>  >>>>
>  >>>> what am I missing?
>  >>>>
>  >>>> much lost
>  >>>> Jason.
>  >>>>
>  >>>
>  >>>
>  >>
>  >
>  >
> 
> 
Received on Friday, 3 November 2006 09:49:29 GMT

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