> >>
> >>> 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?
> 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.
I tried following along AutoCreateDomainObjectContainer, but to be honest I
got quite lost in the specifics. But I think I understand the basic
principle. As I understand it, in your suggestion, I'd register my custom
AutoCreateDomainObjectContainer in place of my JDocBookConvention, or my
JDocBookConvention would extend AutoCreateDomainObjectContainer. Currently I
do:
project.getConvention().getPlugins().put( "jdocbook", new JDocBookConvention(
this ) );
which defines routing for the base jdocbook {} closure to my
JDocBookConvention. So as I understand it, the basic principle of the
AutoCreateDomainObjectContainer would be that rather than the current, simple
call to ConfigureUtil.configure I'd instead do this determination of where to
route. As far as I could see in AutoCreateDomainObjectContainer, this boiled
down to the hasProperty checks. But this is the same part I struggled with
when I first asked this question. How do I know whether the property
currently being processed by configure is a new book config name or an actual
property on the "shared config"? Do I simply hard-code the various property
names of the configuration object (JDocBookConfiguration)?
---
Steve Ebersole <[email protected]>
http://hibernate.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
