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. >>>> 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. >> - 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. > >> 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? 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. :-) Please comment about this. Best Regards, Antonio Gallardo.
