Ok, so I had a good idea, I just implemented it completely wrong.
Lou and I have been having a side discussion, and I think what I
concluded is that I will make two new methods on basevaluecomponent,
`present` and `accept` that are used to convert the value to/from a
string representation according to the type. Simply from a
documentation point of view, it was obvious that applyData/updateData
were bad names for what I was trying to do.
`present` will get the appropriate dependency computation (basically
it depends on type and the dependencies of getValue), and it will use
getValue to get the value to be presented, which allows subclasses to
have arbitrary computations to determine the value they represent. It
turns out that then updateData and applyData can be implemented
directly in terms of present and accept, but they will not have any
dependencies, which as you noted will cause weird side-effects in
subclasses that override updateData.
A revised change will be forthcoming.
On 2008-11-15, at 09:20EST, André Bargull wrote:
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
