Thanks, excellent response. I wasn't aware of many of those features (e.g. references for event handlers, placement.)
Can you place new views on the same level as other views, or only inside them? For example, I'm trying to use the datacombobox with a custom internal class. This works great for the floating list, but the text area that shows the selection begins to look pretty anemic. Take the example of having color names, and a little color square showing what the color looks like. You click on the combobox, and you see the colors, but once you select one, you just see the name. You can get around it with something like:
<class name="dcolorbox" extends="datacombobox" itemclassname="dcbcolorlistitem">
<view
bgcolor = "${classroot.value}"
width = "10"
height = "10"
x = "5"
y = "5"/>
<handler name="oninit">
this._text.setAttribute('x',20)
</handler>
</class>
This takes advantage of knowing the fixed size of the view being added to shift the existing text attribute over on init. That type of thing doesn't work for variable lengths. Is it possible to place the view before the text, and then use a layout?
-Dave
-----Original Message-----
From: P T Withington [mailto:[EMAIL PROTECTED]]
Sent: Mon 9/18/2006 1:38 PM
To: Hogarty, David A.
Cc: Not Zippy; James Howe; [email protected]
Subject: Re: [Laszlo-user] Code Refactoring?
On 2006-09-18, at 09:48 EDT, Hogarty, David A. wrote:
> I think you missed my meaning. I'm familiar with the capabilities
> described in the blog post. What I'm looking to do is to be able to
> modify EXISTING internal views in the instantiation, whereas
> currently you can only add new views. If you look at the example
> again, I'm trying to attach a new event to an existing internal
> view. This allows better code reuse, e.g. a generalized form with
> customizeable submit actions, etc. Possible syntaxes for this new
> capability are shown below:
>
> <class name="foo">
> <view name="a" />
> <button name="b">
> <view name="c" />
> </button>
> </class>
>
> <!-- new event selection syntax using a _javascript_ _expression_ under
> the class context -->
> <foo>
> <method event='this.b.onclick'>
> //some code
> </method>
> </foo>
This should work in the current system. You are allowed to add
methods to instances. The [modern](http://wiki.openlaszlo.org/
Event_and_handler_tags) syntax is to say:
<foo>
<handler name="onclick" reference="this.b">
...
</handler>
</foo>
> <!-- full modification of previously defined attributes and
> internals -->
>
> <foo>
> <modify name="a" bgcolor="somecolor" />
> <modify name="b.c">
> <view "d" />
> </modify>
> </foo>
The full generality you propose here is not supported. This is
partly due to the tension between making classes completely malleable
and making code extremely fragile.
For each of the features you modify in your example, with the
cooperation of the class designer you could have the ability to make
the changes you propose in your instance.
To override an event, the class designer has to expose the event
handler:
<class name="foo">
<handler name="onclick" method="handleOnClick" />
<method name="handleOnClick>
...
</method>
</foo>
Then in subclasses or instances you can override handleOnClick.
Similarly, to change the background color, you can expose it as an
attribute:
<class name="foo">
<view name="a" bgcolor="${aColor}" />
<attribute name="aColor" value="blue" />
</foo>
In both these cases, if the class designer wants to permit overriding
of features, they need to expose it in an overridable way, either as
a method or an attribute. I think providing a general way to access
the internals of classes in LZX is an interesting idea, but it seems
inconsistent with the simplicity goals of LZX.
In the case of adding view, you can use the `placement` attribute to
achieve what you want:
<foo>
<view name="d" placement="c" />
</foo>
I know this doesn't answer your question, but maybe there is more
flexibility here than you were aware of.
We should keep exploring this area, because I know that you are not
the only one who has had this issue. Many times people want to
repurpose a component, and currently the only way to get all the
flexibility that you might need is to either a) re-implement the
component, exposing new API's, or b) copy the source and fork the
component. Neither of these is a great choice. Aspect-oriented
programming is an approach that is used in other O-O languages to
achieve these goals. Perhaps there is something from that discipline
that could be adopted to LZX.
Finally, we are putting the finishing touches on a new CSS
implementation that will go a long way to solving at least _some_ of
the issues with component reuse, although that still will require
forethought by the class designer to make the correct attributes of
their class styleable.
> As alluded to in my previous post, you can achieve these same goals
> using _javascript_ (in the oninit event, not the onconstruct like I
> used in the example, because internal views need to have already
> been constructed to be referenced), but the syntax is ugly and it
> requires too deep a knowledge of lazlo for the average user.
>
> -Dave
>
> -----Original Message-----
> From: P T Withington [mailto:[EMAIL PROTECTED]]
> Sent: Sat 9/16/2006 9:12 AM
> To: Hogarty, David A.
> Cc: Not Zippy; James Howe; [email protected]
> Subject: Re: [Laszlo-user] Code Refactoring?
>
> On 2006-09-15, at 17:39 EDT, Hogarty, David A. wrote:
>
>> On this same note, I think it would be beneficial to allow post-
>> definition modification of a classes internal views at
>> instantiation, for example:
>>
>> <class name="foo">
>> <view name="a" />
>> <button name="b" />
>> </class>
>>
>>
>> <foo>
>> <method event='this.b.onclick'>
>> //some code
>> </method>
>> </foo>
>>
>>
>> Can we already do something like this?
>
> Yes. See this nifty blog entry of Oliver's on [instance-first
> development](http://osteele.com/archives/2004/03/classes-and-
> prototypes).
>
>
_______________________________________________ Laszlo-user mailing list [email protected] http://www.openlaszlo.org/mailman/listinfo/laszlo-user
