Berin Loritsch wrote:
Stephen McConnell wrote:
Berin Loritsch wrote:
I have some rudimentary support for using attributes to represent components and their roles. The core mechanisms in Fortress have not changed, but I am adding a new RoleManager that can read a resolve components from several different jars automatically.
It will be used in my GUIApp system--but I want to put it in Fortress before we release as well. I want to mark the services and components with a minimal set of attributes--which will get our users used to added functionality in Merlin and Phoenix.
I can think of the following *core* attributes:
@avalon.service -- Required for marking role interfaces.
Are you using this as a marker attribute in an interface soruce or a attribute of a component class?
i.e. @avalon.service <---- this is a work interface
This one. It is much easier to mark an interface with a flag than to rely on the fact that I have a memory like a seive.
LOL :-)
Know what you mean. However, it's problamatic in that it locks you into a model where the interface can only be a work interface and cannot be applied as a internal interface. I've thought about the same approach with respect to lifecycle stages in Merlin and reached the conclusion that its too restrictive - ended up focussing on explicity declaring the published services, lifecycle extensions, etc. in the component. But keep in mind that what I have been doing is still real early.
Cheers, Steve.
--
Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
