Martin Grotzke wrote:
> 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.
What if configure just returned configuration information and did not
instantiate/initiate, which instead could be performed by the
getWadlGenerator() method on that configuration information?
The use of the builder is then just a convenient ease of use way of
constructing a list or map of configuration stuff.
Paul.
> 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.
>
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109