Re: [Woody] Boolean widget as a combobox

[Sylvain Wallez]

Antonio Gallardo wrote:

Joerg Heinicke dijo:
 

On 21.01.2004 17:18, Sylvain Wallez wrote:
   

Do you mean you want to remove <wd:booleanfield> and add a styling
type="checkbox"?
             

Yep. This will be clear and for another part a "faster" parsing of
definition.
           

Sorry, I don't understand that sentence :-/
     

"Faster" parsing should mean one widget-type less I guess.
   

Yes. Exactly in one case in the "if" parsing branch of woody widgets.

I am from the old schools where every nanosecond faster matters. This is
why I am changing some of the "if" constructions in some parts of the
Cocoon code. Trying to have the "normal" behavior" as first in a "if"
construction. AFAIK, this avoid stoping the pipeline inside the processor
or virtual machine. Maybe this is not too useful in Java.
 

Mmmmh... in that particular case, this is not a "if", put a lookup in a 
Map, where adding one more widget type doesn't make a real difference. 
Moreover, this lookup occurs only at the form definition load time, 
which is a one time cost as the definition is cached.

WDYT?
         

Sounds reasonable.
       

Sorry, not to me. I don't think checkbox fits naturally as a field
styling:
- using a checkbox for a field with a selection-list only applies to
lists having exactly 2 values.
     

Hmm, indeed, seeing it the other way around makes no sense.
   

Can we agree that the <booleanfield> is just a rendering issue? Then why
we need to define it at definition stage of the woody form?
I know the decision is hard to take. This is why I want to discuss it
further before to take a decision.
 

This is not just a rendering issue: a booleanfield has no validator and 
its implementation is therefore much more simpler and thus faster than 
field. Every nanosecond counts ;-)

- an HTML checkbox returns only a value or a null, but cannot switch
between value1 and value2 without some hidden fields with JS tricks.
     

That's at least something is handable automatically.
   

Yep. This was the intention of the first post. Later was posted if we need
to render a booleanfield as a combobox, then we need to define the
booleanfield as a normal field. That clearly breaks the idea of data
definition. To me de data definition must be done without thinking how we
will render it.
 

Exactly, and I also found that having to choose between booleanfield and 
field depending on the rendering was not clean. With the 2-items 
selectionlist, this problem disappears and we can use <wd:booleanfield> 
for all boolean values. Moreover, this selectionlist can even be defined 
in the template (in <wi:styling>) as it's useful only to define the 
displayed labels, but not to define the values, which are always true/false.

Actually, I think we should add more stylings to booleanfield (e.g. list
and radio) along with the ability to have a selection-list with exactly
2 items.
     

Ok.
   

Hmm.... not sure. Why rendering must be part of a data definition issue?
 

Mmmh... we have a very specific issue here related to how HTML handles 
checkboxes: a null value (i.e. parameter not present on the request) 
means "false", and this fact is unique to booleans, and cannot be 
handled by the current field/datatype mechanism which relies on the 
request parameter to be non-null.

Then we can have also a doublefield, longfield, etc. But this broke the
idea too. We already have a datatype element inside the widget that define
what kind of datat the widget will use.
Based on that the booleanfield seems to be like a hack. :-)
 

Mmmh... (again!), thinking further, maybe accepting an empty input value 
should be part of the Convertor contract (which is not the case today): 
we could then have the boolean convertor return false when the value is 
null or equals "false", and all other convertors (int, float, string, 
etc) generally return null when the value is null also. In that case, 
booleanfield can be removed.

But (things are not simple), we must take care of the fact that an 
unchecked checkbox is not sent at all by browsers: we don't have a 
parameter with an empty value, but no parameter at all! Won't this cause 
problems with other datatypes if we consider equally a non-existing 
parameter and an empty value?

Sylvain

--
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -  http://www.orixo.com