Concerning the "updateData"-dependencies in basevaluecomponent:
I consider this to be a hack, since data-binding and general
representation is mixed together. The contract for data-binding was
actually like: you call "updataData()" on a datapath and then this
datapath (+ dependent datapaths) with a xpath terminal-selector will
call "updataData()" on its immediate-parent (any LzNode) to get the
textual representation for the data-element. This textual representation
is just the "value" for the general components (a quite abstract
approach, because there is no further information), but user-defined
components likely compute more complicated strings or trigger any
side-effects.
With that change, the data-binding api is changed as a whole. You
propose "updataData()" as a general way to get textual representation
for anything:
Called by a datapath to retrieve the value for a data
binding, but can be used in general to get a string
representation of a typed value.
On the one hand, as I already said, I consider this to be a hack, kind
of "overloading semantics". And on the other hand, "updataData()" as a
name for a method which returns textual representation, is simply
misleading. As a novice programmer in OpenLaszlo, I wouldn't expect
"updataData()" as a way to get a string, I'd rather expect that the
method is connected to data-binding. So I think it's better to add a new
method to basevaluecomponent, which returns the value as a string.
Here is a simple example using standard components, which shows the
side-effects I mentioned earlier:
If you enter text in the left edittext, you'll get "ontext"-events.
But if you enter text in the right edittext, you won't get any
"ontext"-event!
---
<canvas debug="true" layout="axis:x;spacing:10" >
<view layout="axis:y;spacing:5">
<edittext name="edt1" >
<handler name="ontext" >Debug.write('ontext for %w', this)</handler>
</edittext>
<text text="${this.parent.edt1.updateData()}" />
</view>
<view>
<edittext name="edt2" >
<handler name="ontext" >Debug.write('ontext for %w', this)</handler>
</edittext>
<text text="${this.parent.edt2.text}" />
</view
</canvas>
---
Change 20081114-ptw-0 by ptw at dueling-banjos.home <http://www.openlaszlo.org/mailman/listinfo/laszlo-dev> on 2008-11-14
12:07:45 EST
in /Users/ptw/OpenLaszlo/trunk
for http://svn.openlaszlo.org/openlaszlo/trunk
Summary: Add `type` to basevaluecomponent
New Features:
You can now declare the `type` of a component's value, to get it
to interact correctly with a databinding or other text
input/output
Bugs Fixed:
LPP-7340 basevaluecomponent should have a 'type' so you know how
to accept/present it
Technical Reviewer: max (pending)
QA Reviewer: lou at louiorio.com
<http://www.openlaszlo.org/mailman/listinfo/laszlo-dev> (pending)
Details:
slider: Use presentAttribute and type to label the slider min and
max
baseslider: Use updateData (which uses presentAttribute and type)
to label the thumb.
baseformitem, basevaluecomponent: Move `type` from formitem to
valuecomponent.
basevaluecomponent: Add default applyData and updateData methods
so value can be set and retrieved as a string according to its
type. Add dependency methods for getValue and updateData so they
can be used in constraints.
Tests:
Test case from bug correctly labels slider range and thumb with
color values.
Files:
M lps/components/lz/slider.lzx
M lps/components/base/baseslider.lzx
M lps/components/base/baseformitem.lzx
M lps/components/base/basevaluecomponent.lzx
Changeset: http://svn.openlaszlo.org/openlaszlo/patches/20081114-ptw-0.tar
