> -----Original Message-----
> From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]]
> Sent: Monday, February 05, 2001 14:36
>
> 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.
Yes, HTML.
> > From: Paulo Gaspar [mailto:[EMAIL PROTECTED]]
> >
> > ...
> >
> > 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 replaceable /
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.
For me, that would be enough.
> 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 :)
Again, I also do not want multiple algorithms. Just "plugability" for them.
> > ...
> >
> > 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.
Of course. That is why I said, about the Parser class:
"The Parser is just a convenient holder for the reference to the
IntrospectionBuilder which avoids extra references."
My "convenient" is directly connected with "avoids extra references" and so
on.
It has to do with performance/flexibility concerns.
The Parser class is also where the ASTIdentifierNode, ASTMethod,
ASTIdentifier
and ASTReference nodes are created. That also makes it easier to set what
strategy such nodes should use - without knowing whatever that strategy
really
does, of course.
> >
> > ...
> >
> > 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' ? :)
=:o)
I was thinking on that one when I wrote "as much compatible as possible..."
> >
> > ...
> >
> > 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
Thanks a lot. I think that ASTIdentifier would be enough for my needs but I
am still volunteer to centralize introspection calls and make the thing
plugable.
What about if I give it a try, test it and get back to you with the changes
I made, so you can evaluate it?
Have fun,
Paulo
