I would actually vote for a Spring-like approach to component
configuration. If you check out Spring Transaction support (and other
stuff too), they actually have an abstract hierarchy of configuration
classes (in the sense of implementation-agnostic data structures, not
abstract classes). For example, this one:
http://www.springframework.org/docs/api/org/springframework/transaction/TransactionDefinition.html
It is a standard configuration interface. It allows for several
implementations and for several *sources*. The "source" lets the engine
read its configuration:
http://www.springframework.org/docs/api/org/springframework/transaction/interceptor/TransactionAttributeSource.html
This transaction source allows the framework to read configuration from
annotations, from XML files, etc....
Of course this would work a bit different for web APIs. I could imagine
a Hivemind configuration source that could be overridden using standard
Hivemind contributions (to embed components) or annotations being
replaced by forced XMLs. Who knows... it would be necessary to test
which implementations are actually needed and which not. But this
example can be a good pointer.
OTH, I'm wonder why Tapestry doesn't have a runtime component model ;).
--
Ing. Leonardo Quijano Vincenzi
DTQ Software
Brian K. Wallace wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Leonardo Quijano Vincenzi wrote:
I would rather keep the XML files around to *override* the annotations,
not because I can't use Java 5.0.
Amen! [with a caveat that it should be _easy_ (whatever 'easy' is) to
override] We'll have to see how this plays out.
As for the use of JDK 5.0, well... this is a release that's a ... year
from now? And we'll have to maintain backwards compatibility with Java
1.1 or 1.2 or whatever at a time when - I think - most people are
actually thinking of moving forward. Now this debate has already
happenned... right?
In moving from 4.X to 5.X it is possible to require 1.5 (guess it's
*possible* anytime, but a major revision jump would be the logical
place). And as you said - 5.0 is no where near even alpha so there's
time for the 4.X thread to mature before we need to 'debate' much.
I'm +1 to require JDK 5.0 but -1 to remove the XMLs but I guess we'll
have a lot of time to discuss that.
Brian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
iD8DBQFEOzRvaCoPKRow/gARAiBnAJwPOCaU748TLqCzGnvIKicPC9RGsgCgsQPx
XDI6TJfGsoR95sd9xlSjnT8=
=v0Nk
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
