I was thinking that it was analagous to $path('foo:/bar/@value'). And, to answer Tucker's question, I was just trying to think of some concise langauge for 'search my children for one with a 'ref' attribute with a spacific value. Maybe your poolside musing or inspirations from other folks on this list can suggest clearer syntax. I think 'parent...foo' is interesting, but I'd like to hear other ideas.
Cheers,
Sarah
On Sat, Oct 28, 2006 at 3:23 PM, Geert Bevin wrote:
> 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:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> 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
>
>
