Listcontrol bug

Jonty wrote

I'm recreating the functionality of hotmail checkboxes in an xforms list control. I have a bug.

The attached files runs in the sandbox. To recreate the bug:

1. Set top box to true (I am using nightly build so for me this is checkbox, but in sandbox you need to write "true"). All boxes below get set to true.
2. Set top box to false. All boxes below get set to false.
3. Set top box to true again. All boxes below get set to true, but top box gets set to false.

In my example, I would expect (3) to occur all the time as when the top box changes the other boxes, the action on that box gets fired causing top box to go to false.

test.xhtml

Erik Bruchez wrote

Jonty,

I tried this again, and it works as expected. I am not sure why you are
hitting the problem but I can't reproduce it with a recent build.

-Erik

Jonty wrote:
> The bug in the first post still stands, but I have amended the code to
> something that I believe should work. It is very close to the functionality
> I want, but it is still buggy. I'm not convinced the OPS event model is
> entirely stable, or perhaps I am overlooking something.
>
> http://www.nabble.com/file/p11254053/test.xhtml test.xhtml
>
> To recreate the new bug in the new xform, click the top checkbox. Now
> uncheck and check one of the article checkboxes. All boxes should be checked
> but are not. If, however, you uncheck all boxes, then check the 3 article
> boxes individual, it does work. Anyone got an idea what is causing this or
> perhaps a better way to achieve my goal?
>
>
> Jonty wrote:
>> I'm recreating the functionality of hotmail checkboxes in an xforms list
>> control. I have a bug.
>>
>> The attached files runs in the sandbox. To recreate the bug:
>>
>> 1. Set top box to true (I am using nightly build so for me this is
>> checkbox, but in sandbox you need to write "true"). All boxes below get
>> set to true.
>> 2. Set top box to false. All boxes below get set to false.
>> 3. Set top box to true again. All boxes below get set to true, but top box
>> gets set to false.
>>
>> In my example, I would expect (3) to occur all the time as when the top
>> box changes the other boxes, the action on that box gets fired causing top
>> box to go to false.
>>
>>  http://www.nabble.com/file/p11235606/test.xhtml test.xhtml
>>
>


--
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/



--
You receive this message as a subscriber of the ops-users@objectweb.org mailing list.
To unsubscribe: mailto:ops-users-unsubscribe@objectweb.org
For general help: mailto:sympa@objectweb.org?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Erik Bruchez wrote

Mmm, that makes it difficult to solve ;-) What browser are you using?

-Erik

Jonty wrote:
> Thanks for looking at it.
>
> I have downloaded the lastest nightly build and both bugs are still there
> (100% reproduceable). They also occur in the sandbox on the website (you
> just have to type in true).
>
>
> Erik Bruchez wrote:
>> Jonty,
>>
>> I tried this again, and it works as expected. I am not sure why you are
>> hitting the problem but I can't reproduce it with a recent build.
>>
>> -Erik
>>
>> Jonty wrote:
>>> The bug in the first post still stands, but I have amended the code to
>>> something that I believe should work. It is very close to the
>>> functionality
>>> I want, but it is still buggy. I'm not convinced the OPS event model is
>>> entirely stable, or perhaps I am overlooking something.
>>>
>>> http://www.nabble.com/file/p11254053/test.xhtml test.xhtml
>>>
>>> To recreate the new bug in the new xform, click the top checkbox. Now
>>> uncheck and check one of the article checkboxes. All boxes should be
>>> checked
>>> but are not. If, however, you uncheck all boxes, then check the 3 article
>>> boxes individual, it does work. Anyone got an idea what is causing this
>>> or
>>> perhaps a better way to achieve my goal?
>>>
>>>
>>> Jonty wrote:
>>>> I'm recreating the functionality of hotmail checkboxes in an xforms list
>>>> control. I have a bug.
>>>>
>>>> The attached files runs in the sandbox. To recreate the bug:
>>>>
>>>> 1. Set top box to true (I am using nightly build so for me this is
>>>> checkbox, but in sandbox you need to write "true"). All boxes below get
>>>> set to true.
>>>> 2. Set top box to false. All boxes below get set to false.
>>>> 3. Set top box to true again. All boxes below get set to true, but top
>>>> box
>>>> gets set to false.
>>>>
>>>> In my example, I would expect (3) to occur all the time as when the top
>>>> box changes the other boxes, the action on that box gets fired causing
>>>> top
>>>> box to go to false.
>>>>
>>>>  http://www.nabble.com/file/p11235606/test.xhtml test.xhtml
>>>>
>>
>> --
>> Orbeon Forms - Web Forms for the Enterprise Done the Right Way
>> http://www.orbeon.com/
>>
>>
>>
>> --
>> You receive this message as a subscriber of the ops-users@objectweb.org
>> mailing list.
>> To unsubscribe: mailto:ops-users-unsubscribe@objectweb.org
>> For general help: mailto:sympa@objectweb.org?subject=help
>> ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
>>
>>
>


--
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/



--
You receive this message as a subscriber of the ops-users@objectweb.org mailing list.
To unsubscribe: mailto:ops-users-unsubscribe@objectweb.org
For general help: mailto:sympa@objectweb.org?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Alessandro Vernet wrote

Jonty,

On 6/27/07, Alessandro Vernet <avernet@orbeon.com> wrote:
> I was able to reproduce this issue. We are currently investigating
> this one. In the meantime, here is the corresponding bug:
> [...]

Erik and I tried this again today, and we can't reproduce the problem
anymore. Maybe this was a side effect of some other problem which has
been fixed in the last few days. Let us know how it works for you
using a nightly build.

Alex
--
Orbeon Forms - Web 2.0 Forms, open-source, for the Enterprise
http://www.orbeon.com/



--
You receive this message as a subscriber of the ops-users@objectweb.org mailing list.
To unsubscribe: mailto:ops-users-unsubscribe@objectweb.org
For general help: mailto:sympa@objectweb.org?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Alessandro Vernet wrote

On 7/25/07, Jonty <jontycurtis@hotmail.com> wrote:
> Been busy for a bit, but just downloaded the latest nightly build. Bug is
> still 100% reproduceable.

I am still unable to reproduce this. I tried this on both Firefox and
IE7. Here is what I am doing, maybe you can tell me if there is
anything I should do differently to reproduce this:

http://www.screencast.com/t/TdtqW_Fu

Alex
--
Orbeon Forms - Web 2.0 Forms, open-source, for the Enterprise
http://www.orbeon.com/



--
You receive this message as a subscriber of the ops-users@objectweb.org mailing list.
To unsubscribe: mailto:ops-users-unsubscribe@objectweb.org
For general help: mailto:sympa@objectweb.org?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Alessandro Vernet wrote

Jon,

On 7/26/07, Jonty <jontycurtis@hotmail.com> wrote:
> This is the bug:
>
> 1) Check top box - all boxes are selected
> 2) Uncheck an article box - top box gets unchecked
> 3) Check the same article box - all boxes get unchecked
>
> The correct behaviour for 3 should be that all boxes are checked.
> Interestingly, if you clear all boxes then check each article individually,
> the top box gets checked. This means that identical states are producing
> different results depending on how you got there.

This is not really a bug; here is what happens:

When everything is checked, if you uncheck the first item, your code
unchecks the "all" checkbox. This is correct so far. But because you
do this, the xforms-value-changed on the "all" is called, and it
unchecks all the check boxes.

In fact what you want to do here is react to the user changing the
value by a click on a check box, not the value changing because it was
set by an <xforms:setvalue>. The event xforms-value-changed does not
make this difference for you.

Another event you could use is xforms-select. This event is not
supported. And even if it was, it is unclear to me if xforms-select
should be called when the checkbox becomes selected because of a user
clicked on the checkbox, or for any reason.

In the meantime, I wouldn't use check boxes for this. Instead I would
use triggers, and have 2 triggers for each line. On represents the
checked state, the other one the unchecked state. Only one of the two
is displayed at any given time. You can even use images of check boxes
if you want to be fancy :).

Alex
--
Orbeon Forms - Web 2.0 Forms, open-source, for the Enterprise
http://www.orbeon.com/



--
You receive this message as a subscriber of the ops-users@objectweb.org mailing list.
To unsubscribe: mailto:ops-users-unsubscribe@objectweb.org
For general help: mailto:sympa@objectweb.org?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Alessandro Vernet wrote

Jonty,

On 8/7/07, Alessandro Vernet <avernet@orbeon.com> wrote:
> OK, I see. Yes, that is unexpected. For now, I have added this bug:
>
> http://forge.objectweb.org/tracker/index.php?func=detail&aid=307407&group_id=168&atid=350207

This one is fixed and now your example behaves as I would expect. Let
us know if this work for when you get a chance to try this out with a
nightly build.

Alex
--
Orbeon Forms - Web 2.0 Forms, open-source, for the Enterprise
http://www.orbeon.com/



--
You receive this message as a subscriber of the ops-users@objectweb.org mailing list.
To unsubscribe: mailto:ops-users-unsubscribe@objectweb.org
For general help: mailto:sympa@objectweb.org?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws