@avalon.configname Maps to the shorthand name we use in our configuration files.
I think this is Fortress specific. Phoneix resolves configuration fragments based on block names in the assembly file. Merlin resolves configurations at multiple levels (type, profile, and block). However, see notes towards the end of the reply.
I understand, and can make it happen that way. However I *really* don't like instance based short names. An XML element should stand for the same implementation all the time. It makes it really simple to understand.
@avalon.scope Maps to a set of constants ("container", "thread", or "request") to represent the type of lifestyle it must support.
I'm a little confused on this one - if we are talking about lifestyle then should this not be something like [singleton|thread|pool|transient] (using Merlin terminology here). The [container|thread|request] set seems to be referring to something different.
We currently have no standard on this. I would like to push toward a standard--without forcing implementation types.
Alternatively if you absolutely have to specify the handler by the long name, you can use the @fortress.handler attribute instead.
Ok - I getting the impression that we are talking about lifestyle in which case what is the correlation between Merlin and Fortress here? This is the Merlin summary:
singleton - unique across a virtual machine
Correction: unique across a container.
thread - unique per thread transient - unique per request
AKA pooled
This is definately specific to the Fortress/ECM notion of shorthand name mappings which are basically keys to data entries. If I understand correctly, the shorthand name is a equivalent to the name of the component (or in Merlin terms, the name assigned in type info declaration). If that's correct, the equivalent in Merlin type info structure looks like:
Keys to data *types* which is much more clear.
@avalon:info.name <name> @avalon:info.version <version> @avalon:info.attribute <key> <valaue>
Where avalon:info.name equates to Fortress/ECM shorthand name?
One other thing, in the background work I've been doing I'm using the URN convention of <domain>:<key> - i.e. "avalon:something.whatever.etc". The benefit here is that you can use the domain to establish a dictionary of keys.
Yes, but we need a dictionary of keys that our users can build upon. I would like to get the minimal set done now--which ignores validation arbitrary attributes and version info. Just enough to tell the container what is available.
You see, merlin and phoenix seem to have their own set of naming conventions. I would really prefer if our users don't have to do a global replace on all the attribute names when they upgrad from Fortress to Merlin or Merlin to Phoenix.
Keep in mind that Phoenix has been doing the attributes the longest, so I would tend toward using their conventions.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
