On Wed, 17 Nov 2004 01:59:00 +0100, David J. M. Karlsen
<david@davidkarlsen.com> wrote:
> Albert Kwong wrote:
> > Why not keep it readable by enhancing <schema>? We
> > can add an attribute to <element
> > key='attribute-name'/> or add an attribute to
> > <attribute key='true'/>? Either a List or Map can be
> > injected into the service depending on the type it
> > expects.
>
> That would be even better! This way the semantics of the configuration
> could be verified by <schema> (and configuration of runtime properties
> are done by operations - nice to slit this out in it's own configuration
> contribution section) - but still leave a nice interface to the programmer.
>
I like the idea of a key attribute on <element> or <attribute>, but I
can't make up my mind which one I prefer... I tend towards <element>.
What do others think?
> The same applies for mapping <configuration> over to class-constuctor
> parameters, but as an orderet set of Objects/primitives rather than a list.
>
I don't quite understand this. How is in your example the
<configuration> mapped to a String and an int? I can see that we'd
also here allow mapping the configuration to a Map instead of just a
List.
Something else I think would be cool: With Java 1.5's generics syntax
we could support autowiring of configurations in addition to services.
--knut
> Thus I could have mixed runtime properties (from the configuration) with
> constructor properties (like wiring a service), but doing all this on
> the construction of the object, eg. I would only have to define a
> constructor like this:
>
> public MyClass(String aRuntimeProp, int anotherRunime, SomeService A,
> SomeOtherService B).
>
> and inside the builderFactory:
>
> .....
> <configuration>someconfig</configuration>
> <service>SomeService</service>
> <servuce>SineOtherService</service>
>
> --
> David J. M. Karlsen - +47 90 68 22 43
> http://www.davidkarlsen.com
> http://mp3.davidkarlsen.com
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
|