[Laszlo-dev] combobox and newcombobox

[Elliot Winard]

I think this makes sense.

We should clearly document the difference between the two and note that 
"combobox" is on the rode to deprecation.

How about using the prefix "LSD" for the new LaSzlo Data driven components?
so "LSDComboBox", "LSDGrid", etc.  Note that I'm a big fan of capitalizing
class names.  This would also be a decent way of making the 'new' components
stand out from the old components.
-e


On Thu, 19 Jan 2006, Jim Grandy wrote:

> I've been looking into the task of integrating newcombobox into combobox.
> We've heard a number of requests for improving combobox  by replacing its
> implementation with the one used in newcombobox, and having looked at the
> dataset-related bugs filed against combobox I can see why this would be
> desirable.
> 
> The problem is that newcombobox does not support the direct declarative style
> that many developers use:
> 
> <combobox>
> 	<textlistitem value="1">A</textlistitem>
> 	<textlistitem value="2">B</textlistitem>
> 	<textlistitem value="3">C</textlistitem>
> </combobox>
> 
> Instead, with newcombobox a data-driven style is required:
> 
> <class name="simplecombo" extends="newcombobox"> ... </class>
> 
> <dataset name="dsItems">
>      <item value="1">A</item>
>      <item value="2">B</item>
>      <item value="3">C</item>
> </dataset>
> 
> <simplecombo itemdatapath="dsItems:/item"/>
> 
> (newcombobox is really a base component, so you need a subclass to complete
> the implementation. I'll check in a revised version of newwcombobox-test.lzx
> soon with a more complete example of a newcombobox subclass.)
> 
> So the immediate problem is that newcombobox is simply not compatible with
> combobox. We can't replace combobox without introducing an incompatible (and
> in my opinion undesirable) change.
> 
> Now, some of us are thinking that we'd like to move the components to a more
> data-driven implementation anyway -- the implementation is just simpler -- but
> for components like menu and combobox the direct declarative style is
> important to keep. I've been working on a design that would allow both without
> a lot of complexity in the components implementation, but it requires one or
> two new language features and pretty substantial modifications to the
> components themselves. Clearly this isn't a Sage project, and it probably
> won't be ready until StarAnise at the earliest.
> 
> So, the question is what to do in the mean time. I'd like to propose that we
> adopt newcombobox into the components (with a more descriptive name, of
> course) and leave combobox itself in place. This avoids an incompatible change
> in a dot release (Sage will be 3.2), but recognizes that many developers are
> using newcombobox in production code and gives newcombobox the benefit of
> better QA.
> 
> Thoughts?
> 
> 
> _______________________________________________
> Laszlo-dev mailing list
> Laszlo-dev at openlaszlo.org
> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev