On 25/10/2010, at 1:50 AM, Steve Ebersole wrote:
>>>>
>>>>> Is it better to explicitly group the shared configuration in any way?
>>>>> jdocbook {
>>>>>
>>>>> shared {
>>>>>
>>>>> translations = ['de-DE']
>>>>> format {
>>>>>
>>>>> name = 'html_single'
>>>>> finalName = 'index.html'
>>>>>
>>>>> }
>>>>> ...
>>>>>
>>>>> }
>>>>> ...
>>>>>
>>>>> }
>>>>> Does that gain me anything?
>>>>
>>>> Possibly not from a DSL point of view. But it would be very simple to
>>>> implement:
>>>>
>>>> def shared(Closure cl) {
>>>>
>>>> allObjects(cl)
>>>>
>>>> }
>>>>
>>>> and you wouldn't need to do any magic in the Book class to take care of
>>>> inheritance from the shared configuration.
>>>>
>>>> It is also something we could add to AutoCreateDomainObjectContainer, so
>>>> that the concept of 'shared' configuration would be available to each
>>>> domain object container.
>
> I understand this does not exist today, but if it did would you see this
> "shared configuration" handling in AutoCreateDomainObjectContainer working
> with the base closure, or with a dedicated closure? Or do you see it
> allowing
> either approach?
I think a dedicated closure might be a better option. It's a lot simpler to
implement, both for the container and for the domain objects in the container.
And it's arguably a little better at self-describing its behaviour.
If you care about backwards compatibility, you might add support for both and
deprecate the use of the base closure.
>
>
>> It's certainly possible to do this in a backwards compatible way.
>>
>> One option is that the plugin adds a default book instance. The
>> AutoCreateDomainObjectContainer would delegate first to this default
>> instance, and if the property/method were not found, then continue with
>> what it does now. It might spit out a deprecation warning too, if you
>> configure the default instance.
>>
>> I guess the question is whether it's more pain to change the existing
>> usages or support backwards compatibility in the plugin.
>
> Again, perhaps it is just my lack of knowledge and skill in both Groovy and
> Gradle, but I have to say I think it is more pain than it is worth.
>
> So as I understand it, my configuration/convention object here would need to
> understand the difference between (for example) jdocbook.translations and
> jdocbook.{bookName}.translations and route those to different configuration
> objects. But the only way I can fathom that working is to encode all the
> configuration object names into the handling of the base closure handling. I
> say that because the book names are not known up front, so i cannot use those
> to make the distinction.
It would first check for a matching property or method on the shared object,
otherwise it would assume it is a book name.
--
Adam Murdoch
Gradle Developer
http://www.gradle.org
CTO, Gradle Inc. - Gradle Training, Support, Consulting
http://www.gradle.biz
