cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antonio Gallardo" <agalla...@agsoftware.dnsalias.com>
Subject Re: [Woody] Boolean widget as a combobox
Date Thu, 22 Jan 2004 04:43:50 GMT
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.


Mime
View raw message