Issues with nested repeats

Hi Larry,

I tried but failed to reproduce the bug you are describing. I have
attached my modified view.xhtml from the To-Do List example. Even when
clicking in "slow motion", the insertion always happens just after the
line that contains the "New" link I clicked on.

I have tested this with one of the latest nightly builds, so if you
have this problem with a vanilla 3.0.1, you might want to try it again
with a nightly build (URL below), as as number of bugs have been fixed
since the 3.0.1 release.

http://forge.objectweb.org/nightlybuilds/ops/ops/

As for the reason for having button at the top, the answer is simple:
because with XForms, you can :). I agree: in most cases it is better
to have the actions repeated on every line. And you can do that with
XForms. But it is often hard to implement a single set of buttons with
other technologies, so we have decided to show in that example how
simple that is with XForms.

Alex

On 5/22/06, [hidden email] [hidden email] wrote:

We've tentatively selected Orbeon to implement our company's next generation enterprise-resource planning (ERP) system as it appears that Orbeon currently has the most complete XForms implementation.

I'm currently trying to implement a nested repeat form similar to the todo-list example, and I've run into a strange problem.  If I follow everything exactly as the todo-list example in terms of the placement of the triggers outside of the repeats, everything works fine.  However, if I place the triggers to insert and delete items within the repeats, they don't work correctly.  Specifically, what happens is that the trigger randomly resets the list index to 1 before it performs the insert or delete.  I say random because it doesn't happen all the time, but most of the time.  You can see this in slow motion if you click the button and hold it, before the button is even released, the list index has already been reset to 1.

We would like to be able to place the triggers within the repeats; it's a bit more intuitive for users.  Otherwise, we'd have a have a huge collection of triggers at the top of the form.

I've always wondered why in the todo-list example the buttons were placed outside of the repeats.  (I just tried moving the current todo insert and delete triggers within the todo-list, and I get the exact same behavior.  The list index get reset to 1 before I release the insert or delete buttons).  Is this a known problem?

To reproduce this bug, move the following block of code from the todo-list example to just after the second (nested) repeat.   I had to change the ref on the second trigger to "/lists/@ui:todo-delete-trigger" due to the change of context.

<!-- Create new to do -->
<xforms:group class="actions-action">
        <xforms:action ev:event="DOMActivate">
                <xforms:insert nodeset="/lists/list[index('list')]/todo"
                        at="min((last(), index('todo') + 1))" position="before"/>
                <xforms:setfocus control="todo-description-input"/>
        </xforms:action>
        <xforms:trigger appearance="xxforms:image">
                <xxforms:img src="/images/add.gif"/>
                <xforms:label>Add</xforms:label>
        </xforms:trigger>
        <xforms:trigger appearance="xxforms:link">
                <xforms:label>New</xforms:label>
        </xforms:trigger>
</xforms:group>
<!-- Delete current to do -->
<xforms:group ref="/lists/@ui:todo-delete-trigger" class="actions-action">
        <xforms:action ev:event="DOMActivate">
                <xforms:delete nodeset="/lists/list[index('list')]/todo" at="index('todo')"/>
                <xforms:setindex repeat="todo"
                        index="max((min((index('todo'), count(/lists/list[index('list')]/todo) - 1)), 1))"/>
        </xforms:action>
        <xforms:trigger appearance="xxforms:image">
                <xxforms:img src="/images/remove.gif"/>
                <xforms:label>Remove</xforms:label>
        </xforms:trigger>
        <xforms:trigger appearance="xxforms:link">
                <xforms:label>Delete</xforms:label>
        </xforms:trigger>
</xforms:group>


Larry T. Chen
Software Engineer
Intelenet Communications, Inc.




--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: [hidden email]
For general help: [hidden email]
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: [hidden email]
For general help: [hidden email]
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
  

On 5/23/06, Larry T. Chen [hidden email] wrote:

 Thank you very much for your quick reply.  You're right that I've been
using the plain vanilla 3.0.1 release.   I tried the latest nightly build,
and to my amazement, the bug is gone!

Hi Larry,

I am glad to read that this works for you with our current code. I'll
take this as a reminder that we should work on making a release at
some point not too far in the future :).

Alex

--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: [hidden email]
For general help: [hidden email]
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws