On Wed, 2008-08-06 at 10:34 +0200, Paul Sandoz wrote:
> Martin Grotzke wrote:
> >> I think one could do it as follows:
> >>
> >> class MyWadlGeneratorConfig extends WadlGeneratorConfig {
> >> public List<WadlGeneratorDescription> configure() {
> >> return
> >> generator(WadlGeneratorResourceDocSupport.class).
> >> prop("resourceDocFile", "classpath:/resourcedoc.xml").
> >> add().
> >> build();
> >> }
> >> }
> > So you want to introduce an abstract method configure()? How could the
> > user then create WadlGenerator instances by himself and provide simply
> > the WadlGenerator?
> >
>
> Is the following sufficient?
>
> class MyWadlGeneratorConfig extends WadlGeneratorConfig {
> public WadlGenerator getWadlGenerator() {
> return ...
> }
> }
>
> Alhtough this would require that configure not be abstract, but it could
> throw IllegalArgumentException. The
> WadlGeneratorConfig.getWadlGenerator() impl can call configure.
I wouldn't call configure from WadlGeneratorConfig.getWadlGenerator() as
configure invokes WadlGenerator.init() on all configured generators.
In WadlGenerator.init() you can load files and do anything else, so this
should only be called once to setup the chain of wadl-generators.
One might check if the WadlGenerator that shall be returned in
WadlGeneratorConfig.getWadlGenerator() is already initialized, but then
we would have to synchronize WadlGeneratorConfig.getWadlGenerator()
somehow.
Cheers,
Martin
>
>
> >> i.e. the add is probably redundant:
> >>
> >> class MyWadlGeneratorConfig extends WadlGeneratorConfig {
> >> public List<WadlGeneratorDescription> configure() {
> >> return
> >> generator(WadlGeneratorResourceDocSupport.class).
> >> prop("resourceDocFile", "classpath:/resourcedoc.xml").
> >> generator(...).
> >> prop(..., ...).
> >> prop(..., ...).
> >> build();
> >> }
> >> }
> >>
> >> because the method "generator" signals a new addition.
> >>
> >> You might be able to remove the class WadlGeneratorDescription by using:
> >>
> >> class MyWadlGeneratorConfig extends WadlGeneratorConfig {
> >> public Map<Class<? extends WadlGenerator>, Properties>
> >> configure() {
> >> return
> >> generator(WadlGeneratorResourceDocSupport.class).
> >> prop("resourceDocFile", "classpath:/resourcedoc.xml").
> >> generator(...).
> >> prop(..., ...).
> >> prop(..., ...).
> >> build();
> >> }
> >> }
> >>
> >> But that is a bit of a mouthful. I would be inclined to have a
> >> WadlGeneratorDescriptions class that extends HashMap, if there can be
> >> only one instance of a generator class per configuration:
> >>
> >> public class WadlGeneratorDescriptions extends
> >> HashMap<Class<? extends WadlGenerator>, Properties> { ... }
> >>
> >> class MyWadlGeneratorConfig extends WadlGeneratorConfig {
> >> public WadlGeneratorDescriptions configure() {
> >> return
> >> generator(WadlGeneratorResourceDocSupport.class).
> >> prop("resourceDocFile", "classpath:/resourcedoc.xml").
> >> generator(...).
> >> prop(..., ...).
> >> prop(..., ...).
> >> build();
> >> }
> >> }
> > Replacing the List<WadlGeneratorDescription> is an option.
> > On Friday I'll go on holiday for 3 weeks (next week wednesday I'll be at
> > home for one day again), so I'll focus on the important things.
> > Of course you can tune these things by yourself, perhaps this is also
> > faster than lots of email conversation :)
> >
>
> If you agree to the changes i can have a go.
>
> Paul.