Hi Sarah,
I think that using this notation would be very confusing since the
text between the brackets is supposed to be an expression. Currently
the modifiers change the execution time of the assignment of
expression's result to the attribute. Introducing 'childref' and
'parentref' totally changes the semantics of what the expression does
and actually forcibly turns it into a string literal. I'm not so
certain that this is a good idea.
I do agree though that a solution in the platform is the way to go.
I'll think this through and see if I can't come up with a clear and
non-confusing way to adapt the current language while I'm relaxing at
the pool next week ;-)
Take care,
Geert
On 28 Oct 2006, at 21:45, Sarah Allen wrote:
We do sort of have attributes on attributes (or at least certain
built-in modifiers), like $path{'...'} and $when. I was thinking
that potential alternative syntax for Geert's proposal would be:
<class name="container">
<attribute name="mything" value="$childref{'specialthing'}"/>
</class>
<class name="thing"/>
<attribute name="ref" value="specialthing"/>
</class>
<container>
<view>
<view>
<thing/>
</view>
</view>
<container>
I agree with Geert and Neil that this is a common situation. I ran
into it a lot when working on the components for LPS 2.0 (e.g. list
and listitem). I think it would be great if this was addressed in
the platform, rather than just agreeing that it is a nice pattern
and sharing example code via the incubator.
Sarah
On Wed, Oct 25, 2006 at 11:39 PM, Geert Bevin wrote:
Hi Max,
I totally agree with you here, user-definable attribute types
would be very handy. Another idea might be to allow attributes on
attributes :-) That was actually my first urge. If you allow any
kind of attributes, or even just an "options" attributes like on
the view tag, then something like this wouldn't have to rely on
naming conventions.
I'll try to get a blog post written before the weekend and
otherwise it will have to wait a week since I'm finally going on
holiday ... yeay! ;-)
Take care,
Geert
On 26 Oct 2006, at 05:46, Max Carlson wrote:
Hi Geert,
I'm sorry for not responding sooner - I think this would make a
great contribution for the incubator. One thing I'd really like
to see in Laszlo are user-definable attribute types. Without
adding language features, I'm not sure what to do besides rely on
convention/naming like you're doing here. Rather than relying on
attribute name, you could have attributes eligible for injection
contain a certain _type_ of sentinel object and check all
attributes in the class for this value.
An example/blog post would be great! Laszlo needs to borrow more
from AOP and this is a great step in that direction. Let me
know if you've got an updated version/example. Thanks!
Regards,
Max Carlson
OpenLaszlo.org
Geert Bevin wrote:
So, is there any interest in this? It seems that at least
several people do think that there should be some kind of a
solution to the parent.parent.parent approach. Should I just
post this code on my blog with some examples and leave it be or
would it be suitable for the incubator?
On 18 Oct 2006, at 11:46, Geert Bevin wrote:
Hi everyone,
I've been doing a lot of OpenLaszlo work in the past months and
one of the main problems I found was the coupled nature of
clearly independent classes that still rely on each-other for
global functionalities. For example, you might have a control
strip with buttons that operate on views that are displayed in
a central area. Each of these items can be developed as
individual classes that have a well defined set of API
methods. A user of these classes will then compose these
classes on a canvas and needs to wire them up so that they are
aware of each other. I found that it was much easier to rely
on the hierarchical nature of an OpenLaszlo layout and to
detect the relationships automatically instead of having to
refer to them specifically. This allows the code to be
maintained much more easily since the relationships will not
break if additional levels are added for layout purposes, for
examples.
I developed a simple reference injection mechanism for this and
attached it as a zip archive to this post. It contains both the
'injmanaged' class and a test case.
Would something like this be a worthwhile contribution to
OpenLaszlo itself?
Can it be improved upon? Currently I rely on a prefix of the
attributes to check if they are illegible for receiving the
injected instances. I'd however much rather have a dedicated
attribute type for this or something else that clearly
identifies this functionality instead of relying on a hackish
thing like a prefix. Any thoughts about that?
Best regards,
Geert
<injmanagement.zip>
--
Geert Bevin
Uwyn "Use what you need" - http://uwyn.com
RIFE Java application framework - http://rifers.org
Music and words - http://gbevin.com
--
Geert Bevin
Uwyn "Use what you need" - http://uwyn.com
RIFE Java application framework - http://rifers.org
Music and words - http://gbevin.com
--
Geert Bevin
Uwyn "Use what you need" - http://uwyn.com
RIFE Java application framework - http://rifers.org
Music and words - http://gbevin.com
--
Geert Bevin
Uwyn "Use what you need" - http://uwyn.com
RIFE Java application framework - http://rifers.org
Music and words - http://gbevin.com
