This was the only vote, yet recived... Any other votes for the
other points (in my two initial mails in this thread).
"Geir Magnusson Jr." wrote:
>
> Christoph Reck wrote:
> >
> > "Geir Magnusson Jr." wrote:
> > >
> > > Here are some ideas to incorporate into this discussion :
> > >
> > > I think (and have discussed this with jason, although I won't make any
> > > claims about his agreement on this) that we might want to not be so
> > > accomodating to users on the introspection front. Here's what I am
> > > thinking about, in no particular order (and some we already do,
> > > probably) :
> > >
> > > 0) I think we should, in our introspection, try the literal
> > > interpretation of the reference before we wander of in introspection
> > > flail-land. This is for speed, and we may already do this.
> > >
> >
> > This would require an additional try/catch. How expensive is a
> > try/catch compared to:
> > two method calls
> > a containsKey plus hash lookup
> > stringifying the signature
> > and doing a get
> > which is what the introspector currently does. I guess this must
> > be benchmarked to really find out. Performance issues are future
>
> Why is this the only possible implementation solution?
Well I saw from the commits that you're doing some caching of the
already cached introspection results...
So its following the modern approach: speed and waste memory. (I'm
already locked to 128MB, without funds to upgrade, allways swapping...)
>
> .
> >
> > > 1) I think that we should conform to the bean spec. There is already
> > > much literature and support for it.
> >
> > +1, plus the notion of maps (currently only applied when getting)
>
> You mean for set? -1
Well this is democracy...
>
> > >
> > > 2) I think that we should clearly define and document what our
> > > introspection plan is so a user can code templates to that for speed.
> > > Interested, Christoph?
> >
> > +1
> > I can summarize what has been agreed here in text form, and
> > send it to jcastura for revision and embedding.
>
> excellent
No agreement (votes) yet, so no text...
>
> > >
> > > 3) I think we should consider limiting our introspection plan to not try
> > > anything and everything as a convenience for the users. Why? Well,
> > > consider that we aren't looking for gold or oil here - we are trying to
> > > match a method call or data access in which a programmer and designer
> > > have already sat down and agreed on the API they will use between them
> > > through the context. Of course, it's a nice feature that you can do
> > > things like $foo.bar and the programmer has the freedom to use a method
> > > bar(), getBar() or get("bar") in the object $foo, but does that conform
> > > to the bean spec anyway?
> >
> > No, we are not doing Bean manipulation here, we are pulling data
> > from bean and map objects and transforming it to text.
> >
> > Plus, it should be symmetrical: what I can get with $foo.bar should
> > also allow a #set($foo.bar = "woobie").
>
> Not clear to me why that's true, but that's just my opinion.
OK, Jose Alberto also said there are read-only breans... So shall we
keep the unsymmetry?
>
> > >
> > > 4) My gut reaction is -1 to #set $foo.bar = RHS for some reason, but
> > > will think about it. I think because this is a loaded gun of sorts,
> > > depending upon the class.
> >
> > See the symmetrical requirement above.
> > My example is:
> > #set($COLORS = $defaults.ColorLUT)
> > #set($COLORS.TEXT = "red")
> > to do local overrides.
>
> Why not simply have the users modify the state of the context objects in
> a way allowed by the implementing programmer :
>
> $foo.setBar("yellow")
>
> where setBar returns void. No muss, no fuss. Then the inputs can be
> checked, for example. Otherwise, you can have things like
>
> $colors.text = "frankfurter"
>
> and if you really wanted a color... :)
Using any of the two ways makes no difference.
>
>
> > >
> > > 5) [wacky] I can't come up with a convincing example, but consider if
> > > we allowed users, through a vel.propse property, to tell Velocity to
> > > *only* try the first approach of the introspection plan and then abandon
> > > the search. For specialized cases, I wonder if there would be a good
> > > performance gain. It's like the user is saying "Hey, I promise to be
> > > careful about my reference use in the template, if you (Velocity)
> > > promise to be quick about it...".
> >
> > No, won't work because Java isn't Perl or ksh. Method signature is
> > an issue. Just think about the requirements of the turbine admin
> > app; I believe it wouldn't work then. The example that shows what
> > happens if you do restrict to beans (and strings) can be seen with
> > JavaScript extensions, any method that thakes something else than
> > Strings is not accessible (note that *many* bean methods take
> > primitives and therefore already require introspection).
>
> Yes, but I mean to contrain the introspection to our 'first try' and not
> try other things...
As I said the first try is prone to fail with Java.
>
> > I think theme 0) above should cover the performance issue.
> >
> > >
> > > A little more inline.
> > >[snip]
> > > > ASTSetDirective.render() - to fix a bug I have reported:
> > > > + Assigning a NULL value to the context will remove the entry
> > > > (since Hashmap does not allow it).
> > >
> > > MMmmmm. Are you sure that's a good idea? Doesn't that mean something
> > > could be GC'd if the app was depending upon the context to hold
> > > something? Granted that would happen if the RHS wasn't nul.... hmm.
> >
> > I don't believe the GC is an issue here... If you do a
> > #set($foo.bar = "anything not null"), the previous content would
> > be GC'ed the anyway.
>
> I know, and I am concerned about $foo.bar on the LHS of a #set, for some
> reason. I am working on figuring out a covincing argument.
>
> > The problem can be seen with the following example:
> > Getting element 5 of the testsuite list should returns null
> > So what's in foo after "\#set \$foo = \$list.get(5)":
> > #set $foo = $list.get(5)
> > #if ( $foo )
> > \$foo should have contained NULL (has "$foo")!
> > #else
> > $foo is now correctly NULL.
> > #end
> >
> > The alternative to removing the map entry is to place a constant
> > object in there and within the AST evaluation replace it for null
> > for other usage. I see lot's of complication and no significant
> > improvement with this approach (other than that the key remains
> > in the map).
> >
> > >[snip]
> > > > + possibly: if the rootString is not in the context check with
> > > > the classloader if the dotted path (ASTIdentifiers) point
> > > > to a static method of a class... similar to the xsl:java
> > > > taglib. (if voted for)
> > >
> > > Isn't that slow? The issue would be if something starting with $ wasn't
> > > a reference (such as alt.on.$sale.now ) how much would this slow
> > > rendering down?
> >
> > I agree, drop this possibility.
> >
> > Jason, Daniel, Jon, Bob, Gunnar, any other coments/votes on the
> > original proposal and the patch summary (in this thread, with the
> > comments above).
> >
> > :) Christoph
>
> --
> Geir Magnusson Jr. [EMAIL PROTECTED]
So is the general consensus that we will not support a
#set( $foo.bar.crow = "wacky")
if bar does not support a setcrow (oops I believe we mean setCrow here)?
If this is so, then the convert.WebMacro will not be very useful.
:) Christoph
