If we're trying to avoid XML ("Less XML is good"), then why don't we quit
trying to cram more stuff into the XML descriptor files? Why don't we focus
more on a "next generation" module descriptor provider which doesn't use an
XML descriptor file? The Groovy module descriptor provider is a step in the
right direction, I would think. Maybe we should also look for a
META-INF/hivemodule.groovy file when building the "default registry."
Groovy looks and feels like Java, so maybe we wouldn't get as many
complaints about it. Also, why don't we make it easy to write a module
descriptor provider, so that folks could "hand-code" one if they want? Ok,
my rant/stream of consciousness is done. :-)
-----Original Message-----
From: Pablo Lalloni [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 10, 2005 12:09 PM
To: [email protected]
Cc: Knut Wannheden (JIRA)
Subject: Re: [jira] Commented: (HIVEMIND-121) BuilderFactory should support
lightweight initialization
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_
>6484
>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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You will be married within a year, and divorced within two.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
