Here's what I tihnk it might look like:
invoke-factory (service-id=hivemind.BuilderFactory)
{
construct (class=foo.far.MyService)
{
set-object (property=collab object=service:MyCollab)
set-object (property=bean object=bean:MyBeanFactory:initializer)
}
}
I may change SDL slightly, to allow colons outside of quotes (if it
doesn't already).
The point of this is that if we come up with some other scheme, like
resource:, or jmx:, or god knows what ... we don't have to change
BuilderFactory; we just contribute into the ObjectProviders extension
point to define the new scheme prefix, and the service that will
provide objects using that scheme.
On Tue, 13 Jul 2004 16:41:12 +0200, Achim Huegen <[EMAIL PROTECTED]> wrote:
> 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]
>
>
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
