Talking of reducing XML... I think there's another place for reducing xml and
that is what could be called "implicit configuration-points"...
I frequently have some schemas defined in hivemodules, and then multiple
configuration-point and contributions in many different jars, in this
situation, for every new configuration point I must do:
<service-point id="bla">
<invoke-factory>
<construct class="...">
<set-configuration property="..."
configuration-id="bla"/>
</construct>
</invoke-factory>
</service-point>
<configuration-point id="bla" schema-id="blabla"/>
<contribution configuration-id="bla">
...
</contribution>
I think for this cases, that <configuration-point/> element is pretty in the
way and not adding much info... Maybe it could be implicit when a
contribution is found with a schema-id=".." attribute.
I guess this idea could be extensive to <service-point/> and <implementation/>
but I don't know since I rarely use the second one... correction: I think I
*never* had a need for it, so far.
El Mar 10 May 2005 13:08, Pablo Lalloni escribi�:
> I think Knut is right... another attribute like initializer="...." would be
> better...
>
> That said, I must mention that I feel like this is not the right place or
> way of reducing XML. It is like mixing paradigms to me, mixing strong
> typed, tool friendly XML with "scripting like" expressions that are parsed
> in a different way.
>
> What if we just provide a script container inside <construct/> where we
> could put a groovy or beanshell or whatever for setting properties?
>
> Like:
>
> <construct class="...">
> <set ../>
> <set-service .../>
> <initializer language="groovy">
> service.someProperty = "aValue"
> service.something = false
> </initializer>
> </construct>
>
> This way, the proposed syntax would be just another implementation, say...
>
> <construct class="...">
> <set ../>
> <set-service .../>
> <initializer language="init-string">verbose,timeout=5000</initializer>
> </construct>
>
> And if init-string is the default... well... you know.
>
> El Mar 10 May 2005 12:29, Knut Wannheden (JIRA) escribi�:
> > [
> > http://issues.apache.org/jira/browse/HIVEMIND-121?page=comments#action_64
> >84 6 ]
> >
> > Knut Wannheden commented on HIVEMIND-121:
> > -----------------------------------------
> >
> > I'm wondering if the lightweight initialization should instead be using a
> > different (mutually exclusive) attribute than "class". Maybe "spec" or
> > something. Or alternatively a separate attribute just for this
> > initialization data: params="verbose,timeout=5000".
> >
> > Some things to think about:
> >
> > - How should conflicts be handled? E.g. a nested <set> conflicting with
> > the lightweight initializer. - Should the lightweight initializer support
> > object providers? E.g. "foo=service:foo";? - Should these ideas also be
> > extended to <create-instance>?
> >
> > > BuilderFactory should support lightweight initialization
> > > --------------------------------------------------------
> > >
> > > Key: HIVEMIND-121
> > > URL: http://issues.apache.org/jira/browse/HIVEMIND-121
> > > Project: HiveMind
> > > Type: Improvement
> > > Components: framework
> > > Versions: 1.1
> > > Reporter: Howard M. Lewis Ship
> > > Fix For: 1.1
> > >
> > >
> > > It would be nice if the hivmind.BuilderFactory supported light-weight
> > > initialization, i.e. <invoke-factory>
> > > <construct class="com.example.MyServiceImpl,verbose,timeout=5000">
> > > ... </construct> </invoke-factory>
> > > Properties could be set after the service implementation is
> > > instantiated and properties wired (and autowired) normally. Less XML is
> > > good.
--
Pablo I. Lalloni <[EMAIL PROTECTED]>
Tel�fono +54 (11) 4347-3177
Proyecto Pampa
Direcci�n Inform�tica Tributaria
AFIP
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOBODY EXPECTS THE SPANISH INQUISITION!
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
