On Thu, Mar 26, 2009 at 12:55, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
On Thu, Mar 26, 2009 at 11:56, Vincent Massol
<vincent(a)massol.net> wrote:
Hi,
To start with I propose to model against the plexus annotations but
more simple:
* Component
* Requirement
* Configuration
/**
* Marks a class as a XWiki component.
*/
@Documented
@Retention(RUNTIME)
@Target(TYPE)
@Inherited
public @interface Component
{
Class<?> role();
String hint() default "";
String instantiationStrategy() default "";
}
/**
* Configures a requirement.
*/
@Documented
@Retention(RUNTIME)
@Target({ FIELD, METHOD })
@Inherited
public @interface Requirement
{
Class<?> role() default Object.class;
String hint() default "";
//
// HACK: This is here to support component requirement lists,
which can take a list of hints
//
String[] hints() default {};
}
Note: not sure yet why plexus says it's a hack.
/**
* Marks a field as a configuration element with a default value.
*/
@Documented
@Retention(RUNTIME)
@Target(FIELD)
@Inherited
public @interface Configuration
{
String name() default "";
String value();
}
So for example in the code you'd have:
@Component(role=Parser.class)
public class WikiModelXWikiParser implements Parser...
{
@Requirement
private LinkParser linkParser;
....
wdyt?
Sounds good but I would suggest maybe another way to see it: having an
annotation for each thing. Then it's possible to put the
@ComponentRole annotation on the interface.
That way it's easier to write a component and harder to forget to
register it, it would be a component simply by implementing a
component interface like in:
@ComponentRole(Parser.class)
public interface Parser
{
}
public class DefaultParser implements Parser
{
@Requirement
private LinkParser linkParser;
}
And it is still possible to have a role which is not an interface or
overwrite the role by putting a different @ComponentRole on the
implementation or in a child interface.
And eventually add a way to avoid a class implementing a component
interface to be registered as component (even it's a rare use case I
think)
@ComponentSkip
public class ParserButNotAComponent implements Parser
{
}
Also if each thing is in its own annotation it's easier to extends the
model and still support old code because we don't modify the Component
annotation to add another component related information for example.
I'm still researching.
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne