Re: __defineGetter__

Hi Michi,

2007/3/30, Michael Platzer <[email protected]>:
> Michael Platzer schrieb:
> >   HopObject.prototype.__defineGetter__("first", function() { return
> > this.get(0); });
> >   HopObject.prototype.__defineSetter__("first", function() { return; });
> >   HopObject.prototype.__defineGetter__("last", function() { return
> > this.get(this.count() - 1); });
> >   HopObject.prototype.__defineSetter__("last", function() { return; });
> >
> > This has the nice effect, that i  can do the following with deep macro
> > invocations:
> >
> >   <% this.comments.first.title | truncate max="100" %>
> >
> oops, the above code sample actually does not work. A 'Macro unhandled'
> error is returned. I got mixed up with another solution attempt to my
> problem. sorry for the confusion.

The reason this doesn't work is that property inspection from macros
on HopObjects only supports collections and properties defined in
type.properties. Since first and last are not in type.properties, the
resolution failse. Let's think about this restriction.

> the problem is that i have a collection, and just want to access the
> first element via deep macro invocations. so, let's assume a simple 1:n
> relation between image and comments.

Just a short note on deep macros: I warn against enabling this feature
in an application that has user-contributed skins. The only way to
keep such an application safe is to add access control to macros, and
to "mask" each sensitive HopObject property with a macro that
implements access control.

>   Image/type.properties
>     _comments = collection(Comment)
>     _comments.local = IMAGE_ID
>     _comments.foreign = COMMENT_F_IMAGE
>
> i then tried to define an object-reference named 'firstComment':
>
>   Image/type.properties
>     firstComment = object(Comment)
>     firstComment.local = IMAGE_ID
>     firstComment.foreign = COMMENT_F_IMAGE
>
> But i could not specify a order nor a maxSize, so that i kind of ended
> up with any object, and not the first one. additionally Helma would
> state 'more than one value returned'-messages all the time.

Yep, and I think an object reference is not the right tool to do this.
Object references in Helma don't have all the auto-updating and
checking that collections do and that is necessary to implement such a
feature.

> A much nicer solution would be of course if Helma would directly provide
> sthg like
>
>   <% this.comments.first.title %> or <% this.comments.0.title %>
>   <% this.comments.1.title %>
>   ...
>   <% this.comments.last.title %>
>
> Take a look at http://www.blogr.at/sphere/blogs for example. It displays
> a list of Sites, together with the title and text of the latest story,
> and the titles of the second- and third-last story.

You brought me to something interesting here.

What if we rethink deep macros not as a property path with a macro
invocation at the end, but as a chain of macro invocations? The
current implementation is actually a subset of that, because property
lookup is one way to render a macro. Let me explain: The construct <%
this.comments.last.title %> would result in a chain of macro
invocations where:

1) macro "comments" is invoked on handler "this"
2) macro "last" is invoked on the result of 1)
3) macro "title" is invoked on the result of 2)

This way you could simply write a last_macro() and first_macro() in
HopObject or wherever that returns the last/first element of the
collection to fill in the missing pieces of the chain.

This makes some sense to me. What do you think?

hannes

> Any suggestions for how to solve this problem?
>
> Thanks,
>   michi
>
> _______________________________________________
> Helma-user mailing list
> [email protected]
> http://helma.org/mailman/listinfo/helma-user
>