My MSFT Outlook 2000 client tells me this is 'Plain Text', and because I am behind an 'Exchange Server', it's hard to tell what the real mail message was, so if this is still HTML, please let me know.
More inline.
> From: Paulo Gaspar [mailto:[EMAIL PROTECTED]]
> > > Ok, there is a single point for introspection call which is from:
> > > ASTIdentifier.doIntrospection( Class data )
> >
> > We do it in a few other places as well. Yes, it might be
> good to bring
> > those together into one place, but this is a very expensive
> aspect of
> > Velocity's operation, so we need to be careful.
>
> Sure, but I only found this point as a start to discovering
> properties.
> I might be missing something but it was what I found using
> some searches.
> Can you give me some pointers here?
I was thinking much about this last night. One approach would be to combine the logic of GetExecutor and PropertyExecutor (Since they really do the same thing, in a way), and then let that simple class be replacable / pluggable. Then any wacky property introspection rules can be implemented locally and easily plugged in. Of course, that doesn't give you the full flexibility of making your life miserable, but it's a start.
I persoanally don't really see this as a general problem, and multiple 'discovery' algorithms is certainly something we don't want to put in the distribution and support. (See how much trouble Sun appears to be having keeping their own component model straight ? :)
But, if you have the need, you have the need. You could always simply make your own Get/PropExecutor classes, and just put them into the classpath :)
>
> > > Now, having:
> > > public interface IntrospectionBuilder
> > > { public AbstractExecutor doIntrospection( String identifier,
> > Class data )
> > > throws Exception;
> > > }
> > >
> > > and an extra field for the Parser class like:
> > > public final IntrospectionBuilder introBuilder;
> >
> > Why the Parser class? The parser has nothing to do with
> this - there is
> > nothing static about this : a parsed template must be able
> to be used by
> > multiple contexts at the same time. By this I mean nothing at parse
> > time dictates the introspection information. My servlet
> using a parsed
> > template can use an object with a method getFoo(), and your servlet
> > using the same parsed template can use an object with a
> hashtable with
> > "Foo" as a key, and if the template has $ob.Foo, we both are happy.
> > This feature is one of the most powerful and beautiful, I
> think... :)
>
> The parsed template would still be able to be used by
> multiple contexts at
> the same time. The Parser is just a convenient holder for the
> reference to
> the IntrospectionBuilder which avoids extra references. It
> also opens the
> possibility of creating a parser that works with a different
> discovery rule
> from the rest of the parsers... but I digress a bit here.
We must be using the term 'parser' differently. Currently, the parser has *no* understanding of discovery rules. The discovery rules are implemented in the nodes within the syntax tree.
>
> > > one could replace the introspection call (in
> ASTIdentifier.execute()):
> > > executor = doIntrospection( c );
> > > by
> > > parser.introBuilder.doIntrospection( identifier, c );
> >
> > Sure. Still wondering about the parser bit though.
> >
> > > Profits:
> > > The possibility of having plugable introspection, even
> per Parser.
> >
> > I see the benefit of pluggable introspection just for the modularity
> > alone, although I wouldn't be thrilled about including in the vel
> > distribution anything but a 'standard' introspection
> module, just for
> > sanity's sake, and to avoid encouraging people from doing
> things like
> > accessing things they shouldn't. 'public' and 'private' are
> there for a
> > reason :) Of course, that would be up for a general vote, I guess.
>
> Sure. I also think that only the standard introspection
> module should be
> mounted. Anything else is a customization. At most one could provide a
> sample for documentation purposes.
>
> I already stated before: "The one thing that seems to make
> sense is to keep
> Velocity with a standard discovery mechanism as much
> compatible as possible
> to the beans standard, while allowing people to plug their
> own mechanism at
> Run Time."
:)
Thinking about JMX vs Beanspec, is there a 'standard' ? :)
>
> > > Costs:
> > > - An extra member, and its initialization, for the
> Parser class. Since
> > > a pool of such objects is used, this is a very low cost.
> > > - A couple of extra references and an extra parameter
> to create the
> > > introspection. This is not such high cost either.
> >
> > Yes, after thinking about it, there prollie wouldn't be
> much cost to it.
>
> =:o)
>
>
> > > Well, actually, maybe this costs less than keeping and
> initializing that
> > > "method" field (in the ASTIdentifier class) that is not
> being used any
> > > more.
> > > =;o)
> >
> > Yes, that's just a leftover. Not sure how that relates here.
>
> Doesn't. It was just something I found while researching
> this. Since it
> really has some cost, I am mentioning it so that some one can
> remove it.
It's gone...
> I do not pretend this is a justification for the plug in
> thing. That is why
> I used the smiley. (Ok... maybe I had a bad choice of words.)
I know. Good catch. It's gone. When an unused String becomes the justification for even minor surgery, it's time for this cowboy to mosey on back to the ranch, and go back to a sane language, like, Object Visual Cobol. :D
>
> So, if you give me some pointers on the other starting points for
> introspection that I am missing, I can code something as
> above and give it
> back to you. Sample included.
The places that are important are ASTMethod, ASTIdentifier, ASTReference, and Foreach.java, if you want to hit them all. Generally, they are very plain. The only place there is 'logic' for the Flail-o-Matic approach is ASTReference (for setting values) and Identifier/Method, for getting values
geir
