Berin Loritsch wrote:
What this means is that the @x-avalon-info should be considered differently for service interfaces (element name) and for classes ("type" attribute).
No, it means that your interpretation of the configuration to get at the short name would be different.
Is there an easy way to find out what real class a given shortcut/role is associated with (resolving to)? In
digging into things in Cocoon now I and I'm sure others grep through the roles file and cocoon.xconf to find
where to look for a given implementation. I'm thinking it would be good to provide some way to trace back
from a hint name or service type back to the concrete class.
When Fortress starts up, it spits out all that info in the log file.
However look at this as a strength. Not too long ago I refactored some libraries for my GUIApp application to put all the code in a different package. With ECM, I would have to change the packages, change the roles file, and hope that there were no conflicts between role files. If the class name were listed in a configuration file, then I would have to change that as well.
With Fortress, I only had to use the IDE's move refactoring support and the same configuration worked with the new code--no other edits necessary.
It truly does bring more benefits than liabilities.
Also, the roles file defines default implementation which can be overridden in xconf. Is this the same in fortress? If I want to replace the default implementation of transient-store with my own souped up version (you'll need to
momentarily suspend your disbelief that I'm capable of coming up with one ;) ) how do I do that?
Geoff
Yes, the xconf does allow you to override things--but what real-world requirements would require that to happen? I've been doing this for years, and I can't really think of a reason.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin