We did something like this with Pandora -- oninit we build a tree
composed of only those nodes containing a name attribute. Proved to
be a great way to separate out "business" logic from "display"
logic. Immensely helpful.
On Oct 18, 2006, at 4:36 PM, Geert Bevin wrote:
Hi, it's a little similar, but goes one step further. The instance
of foo is also able to receive the instance of bar that is linked
to it. However, by using the injection of the references, you can
benefit from everything that IoC traditionally provides, ie. you're
not tied to particular implementations. Using the piece of code I
sent, someone can easily create a new class that has another name,
but give it the same refid, which will then be picked up by the
child. As long as it implements the same interface, it will just
continue to work happily. I agree that some kind of solution should
be added to the language or the framework since as you say
parent.parent.parent is in practice just asking for trouble.
On 18 Oct 2006, at 19:10, P T Withington wrote:
This is interesting. I've wanted something like this because I
think it is a cleaner solution to the 'classroot' issue too.
We've talked about overloading `id` in class to mean, not a global
id but a dynamic id. My intuitive approach was that you ought to
be able to say something like:
<class name="foo" id="foo">...</class>
<class name="bar" id="bar">
<attribute name="width" value="${foo.width*0.8}">
</class>
<foo>
<view>
<view>
<bar/>
</view>
</view>
</foo>
and have the reference to foo in bar resolve to the nearest
enclosing foo. Is this the same as what you are trying to do? I
would like to see something like this built in to the language,
because I agree completely that parent.parent.parent is very fragile.
[classroot is a subset of this, it is just as if by default every
class that you define has an id of `classroot`.]
On 2006-10-18, at 05:46 EDT, 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
