Good idea.
Could you give an example of the intended syntax?
I wonder why you use a prefix instead of an additional attribute.
Is this what you are thinking of?
long { "2" } becomes
object { "long:2" }
set { property="prop1" value="2" } becomes
set-object { property="prop1" value="long:2" }
What about specifying the type like this?
object { type="long" value="2" }
set-object { property="prop1" type="long" value="long:2" }
Achim Huegen
Howard Lewis Ship wrote:
Did a little thinking outside the box recently w.r.t. BuilderFactory.
Dieter wanted to "subclass" BuilderFactory to add new parameter
elements ... elements that made it easier to set service properties.
He wanted to do this because BuilderFactory has a fixed number of
elements, corresponding to a fix set of acceptible types: string,
long, service, configuration, etc.
But what if the shoe was on the other foot?
What if BuilderFactory had a set-object element that could, magically,
take any type of object, and didn't care where it came from? Maybe its
an object, or a configuration, or a service ... or even a property
obtained from a service?
The system I'm working on will allow that.
A prefix on the contribution will allow its type to be interpreted, i.e.:
service:foo.bar.Baz
instance:org.foo.bar.Boo
configuration:foo.bar.Blip
bean:foo.bar.Baz:fred
service-property:foo.bar.Baz:glip
Those are examples off the top of my head.
Of course, there'll be a configuration to define prefixes, and
services to implement each type of prefix. If the one you need isn't
available, then you'll be able to supply your own.
Basically, it's a meta-level above translators.
This will remove a lot of redundancy in some contributions: for
example, the Pipeline schema is doubled: to allow service
contributions, or contributions from bean factories.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
