- From: Jason <jeacott@hardlight.com.au>
- Date: Fri, 03 Nov 2006 18:38:36 +1030
- To: Lee Standen <nom@standen.id.au>
- CC: www-forms <www-forms@w3.org>
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 08:08:58 UTC