There is no additional code (let alone Java code - this is not JSP!)
required in templates. The patch I submitted does all the work inside the
Velocity engine. You still write only
$entry.getKey()
in the template. When first faced with an object of a particular class,
Velocity's Introspector (in org.apache.velocity.util.introspection package)
will create a ClassMap for that class that contains all public method
objects on that class. Various parts of Velocity use that map to resolve
method names into method objects. However, due to my patch it will no longer
place public-but-inaccessible methods in the ClassMap, instead it will place
their public-and-accessible counterparts from a superclass/interface. This
method resolution happens only once per class introduced to velocity, and
not on each use of the method (except for those parts of Velocity that
currently do not use Introspector - hopefully they will in near future).
That's all it does.
It does not break the separation of code and presentation.
It does not introduce additional code in templates.
It just solves the problem: you can finally call interface methods on
non-public classes from a template.
Attila.
----- Original Message -----
From: "Stephane Bailliez" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: 2001. augusztus 3. 2:36
Subject: RE: [PATCH] dynamic casting to avoid IllegalAccessExceptions
<snip/>
I'm just wondering here where we should stop in macros..if we continue like
this we'll type plenty of java code in the templates and I'm not sure this
is a good thing. I think we'll completely break the separation between code
and presentation if we do that.
This is the dilemna we are somewhat facing here IMHO.
> interfaces.
> - What if the object was not returned from a method but was stuck into
> Context by code? You could assume only it's a java.lang.Object.
> I hope I was able to convince you.
You are definitely right if we decide to type a lot of Java related code in
the templates just because Java does not support generic and cannot have
typed collection. But is this good ?
--
Stéphane Bailliez
Software Engineer, Paris - France
iMediation - http://www.imediation.com
Disclaimer: All the opinions expressed above are mine and not those from my
company.
