What I would have written
if I had had the time. Perhaps except from the everyday work-thing. ;o)
-----Original Message-----
From: Pablo Lalloni
[mailto:[EMAIL PROTECTED]
Sent: Friday, August 06, 2004 6:31
PM
To: hivemind-dev
Subject: Re: Make hivemind.BuilderFactory
default factory?
El vie, 06-08-2004 a las 11:03, Howard Lewis Ship escribi�:
As I've been looking for ways to reduce the verbosity of HiveMind
MDDs, one thought struck me .... how about making service-id for
<invoke-factory> optional, and default to hivemind.BuilderFactory.
That's the case, 99% of the time!
I think this is a good idea!
As Marc Fleury says: "Defaults! Defaults! Defaults!"
I still get pissed off when I remember that... I think after all, we've
listened to all that noise, at least the useful parts: currently I apply -in
everyday work- that _expression_.
With autowiring working pretty darn well, perhaps we should allow a
simplified <construct class="..."/> element as a even more concise way
to invoke BuilderFactory?
I don't think this is so good... because then, we'll have heterogenous
syntaxes for constructing services with a factory... it is more confusing and
harder to explain.
I've also been pondering having the BuilderFactory autowire writable
List properties to the configuration id with the matching id.� That
raises some questions, such as: what if there's more than one List
property?
Matching configuration-id with service-id?
What about matching last part of configuration-id with implementation property
name?
Or both, so you don't have the multple Lists ambiguity.
Definitely want to implement <interceptor-set> as a way to commonly
apply interceptors to a range of services.
Great news! This is sooo necessary...
Have you read my /brainstorming/ mail about it?
Perhaps modules should provide a default package, and any class names
for the module should be automatically qualified to the package, much
as service ids are qualified to the module id. That would remove a
large amount of repetition.
Definitely a BIG +1 on this. Just earlier today I was thinking of
something like it.
All this FQCN are the ugliest part of my descriptors.
I've also been thinking that we should find a way to generate the
HiveDoc from the in-memory representation of the Registry, rather than
trying to fake it by stitching together the individual XML files. This
would allow the registry.xml to be a very different format than the
MDDs, one that was more sematically rich.� By that, I mean that we
could understand the meaning of contributions properties� (i.e.,
that's a service so make it a hyperlink).
-- Pablo I. Lalloni <[EMAIL PROTECTED]> Tel�fono +54 (11) 4347-3177 Proyecto Pampa Direcci�n Inform�tica Tributaria AFIP > In 2010, M$ Windows will be a quantum processing emulation layer for a > 128-bit mod of a 64-bit hack of a 32-bit patch to a 16-bit GUI for an > 8-bit operating system written for a 4-bit processor from a 2-bit > company that can't stand 1 bit of competition. |
