Leo Sutic wrote:
I'd just like to see what you in Avalon-dev have to say about this:
-----Original Message-----
From: Sylvain Wallez [mailto:[EMAIL PROTECTED]]
Sent: den 29 januari 2003 21:17
To: [EMAIL PROTECTED]
Subject: Re: What is a Parser?
Vadim Gritsenko wrote:
Jeff Turner wrote:
Yes, those deprecation warnings are annoying and
misleading, because
Component is deprecated for Avalon, not Cocoon. Perhaps Cocoon
should have a special avalon-framework-nodepr-4.1.3.jar ,
without the
@deprecated?
By migrating to something that does not require the Component interface
allows you to still use Framework without changing anything. For
example, Fortress uses dynamic proxies to generate a proxy with the
"Component" interface in it. It allows you to use the components any
way you like without having to explicitly mark them as a component.
Code Example:
public interface Action
{
String ROLE = Action.class.getName();
Map act(Map objectModel, String source, ...);
}
public class DemoAction implements Action
{
public Map act(Map objectModel, String source, ...)
{
objectModel.put( "hello", "Hello World!" );
return objectModel;
}
}
notice that neither interface nor component implement Component?
In Fortress, you can still retrieve it from a ComponentManager even if
you *never* have any component implementing the Component interface.
// Sitemap snippet
ComponentSelector selector =
m_manager.lookup( Action.ROLE + "Selector" );
Action action = (Action) selector.select( "Demo" );
Map results = action.act( objectModel, url, ... );
selector.release( action );
Note that there are no exceptions thrown and no need for the
Component interface.
You do need JDK 1.3 unless we have a BCEL enabled proxy generator.
Either way, that is the best solution.
My thinking, exactly... I mean, we are going to support Cocoon 2 for
some time, without changing basic interfaces like
Generator, Action,
etc. And lots of @deprecation in there won't help in raising user's
confidentiality.
Avalon gurus out there - should we fork framework? ...
Answering not to "guru", but to "fork" ;-)
Nope. Just use a proxy so that the Cocoon code does not *need* the
Component interface directly.
The stuff I discussed above will have to be included in the web site.
I believe the ECM also had some support for that--but folks complained
about the JRE 1.3 minimum requirement. Is there any real reason to
limit ourselves like that now?
I can't remember if there is a BCEL enabled proxy generator or not...
But instead of forking, what about a tool that automatically
removes the
deprecation flag on thoses Avalon classes that aren't considered
deprecated in Cocoon ?
A small BCEL-based tool could easily do the trick, and would be used
before committing a new version of Avalon jars in Cocoon's CVS.
Not necessary. A BCEL-based utility class makes it unnecessary to
even declare the Component interface at all.
It seems like the @deprecation of ComponentManager etc. is annoying
some people to a fairly large extent.
I was thinking... Could we remove the @deprecated tags from the classes
in question and just leave it with a note in the JavaDocs saying that
the service.* package is much much better and that you should use it
instead unless you have a reason not to?
As I understand it, every container must support ComponentManager,
Composable, etc. anyway... At least until Avalon 5.
True, but can't we do it in the same manner that Phoenix, Fortress,
and Merlin all do it? Either we upgrade to JDK 1.3 minimum
requirements, or we need to add in a utility class to use BCEL for
the dynamic component proxies.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
