I think this is a good idea!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 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_.As Marc Fleury says: "Defaults! Defaults! Defaults!"
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.With autowiring working pretty darn well, perhaps we should allow a simplified <construct class="..."/> element as a even more concise way to invoke BuilderFactory?
Matching configuration-id with service-id?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?
What about matching last part of configuration-id with implementation property name?
Or both, so you don't have the multple Lists ambiguity.
Great news! This is sooo necessary...Definitely want to implement <interceptor-set> as a way to commonly apply interceptors to a range of services.
Have you read my /brainstorming/ mail about it?
Definitely a BIG +1 on this. Just earlier today I was thinking of something like 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.
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. |
