Form issues

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Form issues

banal
Hello Developers

I'm currently working intensively with qooxdoo forms. Thereby i noticed
some things that are not properly implemented imho.

For one issue i already filed a bug-report:
http://bugzilla.qooxdoo.org/show_bug.cgi?id=1829

The other issue is with Checkboxes or Toggle-Buttons. These classes
implement the IFormElement interface but have an additional property
called "checked".

To successfully handle forms with different elements, it's very handy,
that all elements implement the IFormElement interface. That way it's
rather simple to set/get all element values in a form or add validators
to elements of any type.

Sadly, the widgets mentioned beforehand break some functionality here,
because they have a value *and* a checked property. And as much as i can
tell, these properties are not linked. I'd expect the elements to fire a
"changedValue" event when the checked property changes. Of course the
value should change as well.. i'd toggle between an empty string (not
checked) and the actual value (when checked).

That way, these elements could be used in the same manner as the other
elements that implement IFormElement.

Regards - Roman


------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Form issues

Sebastian Werner
> The other issue is with Checkboxes or Toggle-Buttons. These classes
> implement the IFormElement interface but have an additional property
> called "checked".
>
> To successfully handle forms with different elements, it's very handy,
> that all elements implement the IFormElement interface. That way it's
> rather simple to set/get all element values in a form or add  
> validators
> to elements of any type.
>
> Sadly, the widgets mentioned beforehand break some functionality here,
> because they have a value *and* a checked property. And as much as i  
> can
> tell, these properties are not linked. I'd expect the elements to  
> fire a
> "changedValue" event when the checked property changes. Of course the
> value should change as well.. i'd toggle between an empty string (not
> checked) and the actual value (when checked).
>
> That way, these elements could be used in the same manner as the other
> elements that implement IFormElement.

The "value" property is meaned mainly for serialization proposes in  
these widgets. It's somewhat like in HTML where a unchecked checkbox  
is not regarded in form submission but still has a value. Checked in  
this case is behaves for form submission like the "enabled" property  
for all kinds of input elements.

Cheers,
Sebastian



>
>
> Regards - Roman
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> qooxdoo-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel


------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Form issues

banal

Sebastian Werner wrote:

>> The other issue is with Checkboxes or Toggle-Buttons. These classes
>> implement the IFormElement interface but have an additional property
>> called "checked".
>>
>> To successfully handle forms with different elements, it's very handy,
>> that all elements implement the IFormElement interface. That way it's
>> rather simple to set/get all element values in a form or add  
>> validators
>> to elements of any type.
>>
>> Sadly, the widgets mentioned beforehand break some functionality here,
>> because they have a value *and* a checked property. And as much as i  
>> can
>> tell, these properties are not linked. I'd expect the elements to  
>> fire a
>> "changedValue" event when the checked property changes. Of course the
>> value should change as well.. i'd toggle between an empty string (not
>> checked) and the actual value (when checked).
>>
>> That way, these elements could be used in the same manner as the other
>> elements that implement IFormElement.
>
> The "value" property is meaned mainly for serialization proposes in  
> these widgets. It's somewhat like in HTML where a unchecked checkbox  
> is not regarded in form submission but still has a value. Checked in  
> this case is behaves for form submission like the "enabled" property  
> for all kinds of input elements.
>
> Cheers,
> Sebastian

Hi Sebastion

Ok, that would be another valid solution.. But sadly, that's not the
case. Altering the "checked" property of a form element *doesn't* change
the "enabled" property of said element.

Cheers - roman

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Form issues

banal

> Sebastian Werner wrote:
>>> The other issue is with Checkboxes or Toggle-Buttons. These classes
>>> implement the IFormElement interface but have an additional property
>>> called "checked".
>>>
>>> To successfully handle forms with different elements, it's very handy,
>>> that all elements implement the IFormElement interface. That way it's
>>> rather simple to set/get all element values in a form or add  
>>> validators
>>> to elements of any type.
>>>
>>> Sadly, the widgets mentioned beforehand break some functionality here,
>>> because they have a value *and* a checked property. And as much as i  
>>> can
>>> tell, these properties are not linked. I'd expect the elements to  
>>> fire a
>>> "changedValue" event when the checked property changes. Of course the
>>> value should change as well.. i'd toggle between an empty string (not
>>> checked) and the actual value (when checked).
>>>
>>> That way, these elements could be used in the same manner as the other
>>> elements that implement IFormElement.
>> The "value" property is meaned mainly for serialization proposes in  
>> these widgets. It's somewhat like in HTML where a unchecked checkbox  
>> is not regarded in form submission but still has a value. Checked in  
>> this case is behaves for form submission like the "enabled" property  
>> for all kinds of input elements.
>>
>> Cheers,
>> Sebastian
>
> Hi Sebastion
>
> Ok, that would be another valid solution.. But sadly, that's not the
> case. Altering the "checked" property of a form element *doesn't* change
> the "enabled" property of said element.
>
> Cheers - roman

Hi Sebastian

Sorry, i guess my response wasn't very thoughtful. Of course the element
cannot be set to disabled, otherwise the user won't be able to
re-activate it again ;)

The problem persists however. The Checkbox and Toggle-Button aren't
useful in a scenario where one relies on the capabilities provided by
the "IFormElement" interface, which defines the only common set of
members/properties that are inherited by all Form-Elements. This is
especially important when forms are automatically generated (without
custom code for each element type).

This isn't a top priority issue, but if there's some development on the
form elements on the way, you could maybe consider it.

For my current project, i simply subclassed Checkbox and changed it in a
way that it fits my needs.

Cheers - Roman

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Form issues

Sebastian Werner

Am 22.01.2009 um 22:19 schrieb Roman Schmid:

>
>> Sebastian Werner wrote:
>>>> The other issue is with Checkboxes or Toggle-Buttons. These classes
>>>> implement the IFormElement interface but have an additional  
>>>> property
>>>> called "checked".
>>>>
>>>> To successfully handle forms with different elements, it's very  
>>>> handy,
>>>> that all elements implement the IFormElement interface. That way  
>>>> it's
>>>> rather simple to set/get all element values in a form or add
>>>> validators
>>>> to elements of any type.
>>>>
>>>> Sadly, the widgets mentioned beforehand break some functionality  
>>>> here,
>>>> because they have a value *and* a checked property. And as much  
>>>> as i
>>>> can
>>>> tell, these properties are not linked. I'd expect the elements to
>>>> fire a
>>>> "changedValue" event when the checked property changes. Of course  
>>>> the
>>>> value should change as well.. i'd toggle between an empty string  
>>>> (not
>>>> checked) and the actual value (when checked).
>>>>
>>>> That way, these elements could be used in the same manner as the  
>>>> other
>>>> elements that implement IFormElement.
>>> The "value" property is meaned mainly for serialization proposes in
>>> these widgets. It's somewhat like in HTML where a unchecked checkbox
>>> is not regarded in form submission but still has a value. Checked in
>>> this case is behaves for form submission like the "enabled" property
>>> for all kinds of input elements.
>>>
>>> Cheers,
>>> Sebastian
>>
>> Hi Sebastion
>>
>> Ok, that would be another valid solution.. But sadly, that's not the
>> case. Altering the "checked" property of a form element *doesn't*  
>> change
>> the "enabled" property of said element.
>>
>> Cheers - roman
>
> Hi Sebastian
>
> Sorry, i guess my response wasn't very thoughtful. Of course the  
> element
> cannot be set to disabled, otherwise the user won't be able to
> re-activate it again ;)
>
> The problem persists however. The Checkbox and Toggle-Button aren't
> useful in a scenario where one relies on the capabilities provided by
> the "IFormElement" interface, which defines the only common set of
> members/properties that are inherited by all Form-Elements. This is
> especially important when forms are automatically generated (without
> custom code for each element type).

All time you have to check other things as well. The mentioned  
"enabled" property is also a good candidate to check.

In fact you can use the value (and maybe the name) of each form field,  
but have to test if it supports the enabled and/or checked property  
before adding it to the list of elements to serialize. Checkboxes in  
HTML for example allows some kind of multi selections where many  
fields have the same name which are then send to the server like this:

fieldName=check1,check3,check9

which means

name=value1,value3,value9

qooxdoo perfectly covers HTML here, so it might be comfortable for  
users with such an background but is some kind of re-thinking for  
people with another history.

Cheers,
Sebastian


>
>
> This isn't a top priority issue, but if there's some development on  
> the
> form elements on the way, you could maybe consider it.
>
> For my current project, i simply subclassed Checkbox and changed it  
> in a
> way that it fits my needs.
>
> Cheers - Roman
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> qooxdoo-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel


------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Form issues

Sebastian Werner
In reply to this post by banal

Am 22.01.2009 um 20:51 schrieb Roman Schmid:

>
> Sebastian Werner wrote:
>>> The other issue is with Checkboxes or Toggle-Buttons. These classes
>>> implement the IFormElement interface but have an additional property
>>> called "checked".
>>>
>>> To successfully handle forms with different elements, it's very  
>>> handy,
>>> that all elements implement the IFormElement interface. That way  
>>> it's
>>> rather simple to set/get all element values in a form or add
>>> validators
>>> to elements of any type.
>>>
>>> Sadly, the widgets mentioned beforehand break some functionality  
>>> here,
>>> because they have a value *and* a checked property. And as much as i
>>> can
>>> tell, these properties are not linked. I'd expect the elements to
>>> fire a
>>> "changedValue" event when the checked property changes. Of course  
>>> the
>>> value should change as well.. i'd toggle between an empty string  
>>> (not
>>> checked) and the actual value (when checked).
>>>
>>> That way, these elements could be used in the same manner as the  
>>> other
>>> elements that implement IFormElement.
>>
>> The "value" property is meaned mainly for serialization proposes in
>> these widgets. It's somewhat like in HTML where a unchecked checkbox
>> is not regarded in form submission but still has a value. Checked in
>> this case is behaves for form submission like the "enabled" property
>> for all kinds of input elements.
>>
>> Cheers,
>> Sebastian
>
> Hi Sebastion
>
> Ok, that would be another valid solution.. But sadly, that's not the
> case. Altering the "checked" property of a form element *doesn't*  
> change
> the "enabled" property of said element.

Sure, unfortunately this was not what I meant :)

enabled and checked are not related to each other, but both conditions  
may change whether a field is regarded for serialization proposes.

Cheers,
Sebastian

>
>
> Cheers - roman
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> qooxdoo-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel


------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Form issues

banal
In reply to this post by Sebastian Werner

>
> All time you have to check other things as well. The mentioned  
> "enabled" property is also a good candidate to check.
>
> In fact you can use the value (and maybe the name) of each form field,  
> but have to test if it supports the enabled and/or checked property  
> before adding it to the list of elements to serialize. Checkboxes in  
> HTML for example allows some kind of multi selections where many  
> fields have the same name which are then send to the server like this:
>
> fieldName=check1,check3,check9
>
> which means
>
> name=value1,value3,value9
>
> qooxdoo perfectly covers HTML here, so it might be comfortable for  
> users with such an background but is some kind of re-thinking for  
> people with another history.
>
> Cheers,
> Sebastian
>

Hi Sebastian

Yes you're right. Actually i'm perfectly familiar with HTML and
HTML-Forms but i always had the impression the checkboxes were some kind
of a bastard element in regard to other form elements.
Anyway, that's just me. Maybe the IFormElement interface definition
could have a property "isCheckable" to indicate if we're dealing with a
checkable element? There could be other elements than checkboxes that
could be checkable.. right?

Best - Roman

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Form issues

Sebastian Werner
>>
>>
>> qooxdoo perfectly covers HTML here, so it might be comfortable for
>> users with such an background but is some kind of re-thinking for
>> people with another history.
>>
>> Cheers,
>> Sebastian
>>
>
> Hi Sebastian
>
> Yes you're right. Actually i'm perfectly familiar with HTML and
> HTML-Forms but i always had the impression the checkboxes were some  
> kind
> of a bastard element in regard to other form elements.
> Anyway, that's just me. Maybe the IFormElement interface definition
> could have a property "isCheckable" to indicate if we're dealing  
> with a
> checkable element? There could be other elements than checkboxes that
> could be checkable.. right?

Yes, that would be a great idea IMHO. But I would change it a bit to  
something like:

isSerializable()

which does some kind of vodoo depending on the field. On normal fields  
it just do something like:

return this.isEnabled();

and for checkboxes and toggle buttons it might look like:

return this.isEnabled() && this.isChecked();

What do you think?

Cheers,
Sebastian


>
>
> Best - Roman
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> qooxdoo-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel


------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Form issues

banal


Sebastian Werner wrote:

>>>
>>> qooxdoo perfectly covers HTML here, so it might be comfortable for
>>> users with such an background but is some kind of re-thinking for
>>> people with another history.
>>>
>>> Cheers,
>>> Sebastian
>>>
>> Hi Sebastian
>>
>> Yes you're right. Actually i'm perfectly familiar with HTML and
>> HTML-Forms but i always had the impression the checkboxes were some  
>> kind
>> of a bastard element in regard to other form elements.
>> Anyway, that's just me. Maybe the IFormElement interface definition
>> could have a property "isCheckable" to indicate if we're dealing  
>> with a
>> checkable element? There could be other elements than checkboxes that
>> could be checkable.. right?
>
> Yes, that would be a great idea IMHO. But I would change it a bit to  
> something like:
>
> isSerializable()
>
> which does some kind of vodoo depending on the field. On normal fields  
> it just do something like:
>
> return this.isEnabled();
>
> and for checkboxes and toggle buttons it might look like:
>
> return this.isEnabled() && this.isChecked();
>
> What do you think?
>
> Cheers,
> Sebastian

Yeah, that's way better than my suggestion since it's a general purpose
property. I think this could improve form handling a lot!
Now if one could listen to such a property as well, this would be a
godsend. Maybe a "changeSerializableValue" event... or something :)

Best - Roman


------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Form issues

Sebastian Werner
Hi Roman,

can you please add this to our bugtracking system (http://bugzilla.qooxdoo.org 
) with some hints about your original ideas. Thanks.

Sebastian



Am 23.01.2009 um 09:11 schrieb Roman Schmid:

>
>
> Sebastian Werner wrote:
>>>>
>>>> qooxdoo perfectly covers HTML here, so it might be comfortable for
>>>> users with such an background but is some kind of re-thinking for
>>>> people with another history.
>>>>
>>>> Cheers,
>>>> Sebastian
>>>>
>>> Hi Sebastian
>>>
>>> Yes you're right. Actually i'm perfectly familiar with HTML and
>>> HTML-Forms but i always had the impression the checkboxes were some
>>> kind
>>> of a bastard element in regard to other form elements.
>>> Anyway, that's just me. Maybe the IFormElement interface definition
>>> could have a property "isCheckable" to indicate if we're dealing
>>> with a
>>> checkable element? There could be other elements than checkboxes  
>>> that
>>> could be checkable.. right?
>>
>> Yes, that would be a great idea IMHO. But I would change it a bit to
>> something like:
>>
>> isSerializable()
>>
>> which does some kind of vodoo depending on the field. On normal  
>> fields
>> it just do something like:
>>
>> return this.isEnabled();
>>
>> and for checkboxes and toggle buttons it might look like:
>>
>> return this.isEnabled() && this.isChecked();
>>
>> What do you think?
>>
>> Cheers,
>> Sebastian
>
> Yeah, that's way better than my suggestion since it's a general  
> purpose
> property. I think this could improve form handling a lot!
> Now if one could listen to such a property as well, this would be a
> godsend. Maybe a "changeSerializableValue" event... or something :)
>
> Best - Roman
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> qooxdoo-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel


------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Form issues

banal
Hi Sebastian

I file a bug report (enhancement). I tried to explain as good as i can :)
There you go: http://bugzilla.qooxdoo.org/show_bug.cgi?id=1865

Cheers - Roman

Sebastian Werner wrote:

> Hi Roman,
>
> can you please add this to our bugtracking system (http://bugzilla.qooxdoo.org 
> ) with some hints about your original ideas. Thanks.
>
> Sebastian
>
>
>
> Am 23.01.2009 um 09:11 schrieb Roman Schmid:
>
>>
>> Sebastian Werner wrote:
>>>>> qooxdoo perfectly covers HTML here, so it might be comfortable for
>>>>> users with such an background but is some kind of re-thinking for
>>>>> people with another history.
>>>>>
>>>>> Cheers,
>>>>> Sebastian
>>>>>
>>>> Hi Sebastian
>>>>
>>>> Yes you're right. Actually i'm perfectly familiar with HTML and
>>>> HTML-Forms but i always had the impression the checkboxes were some
>>>> kind
>>>> of a bastard element in regard to other form elements.
>>>> Anyway, that's just me. Maybe the IFormElement interface definition
>>>> could have a property "isCheckable" to indicate if we're dealing
>>>> with a
>>>> checkable element? There could be other elements than checkboxes  
>>>> that
>>>> could be checkable.. right?
>>> Yes, that would be a great idea IMHO. But I would change it a bit to
>>> something like:
>>>
>>> isSerializable()
>>>
>>> which does some kind of vodoo depending on the field. On normal  
>>> fields
>>> it just do something like:
>>>
>>> return this.isEnabled();
>>>
>>> and for checkboxes and toggle buttons it might look like:
>>>
>>> return this.isEnabled() && this.isChecked();
>>>
>>> What do you think?
>>>
>>> Cheers,
>>> Sebastian
>> Yeah, that's way better than my suggestion since it's a general  
>> purpose
>> property. I think this could improve form handling a lot!
>> Now if one could listen to such a property as well, this would be a
>> godsend. Maybe a "changeSerializableValue" event... or something :)
>>
>> Best - Roman
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by:
>> SourcForge Community
>> SourceForge wants to tell your story.
>> http://p.sf.net/sfu/sf-spreadtheword
>> _______________________________________________
>> qooxdoo-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> qooxdoo-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel