Peter Donald wrote:
>
> At 08:15 PM 6/17/2002 +0200, you wrote:
> > > The role name is just that - an arbitrary name. ie Stephen tends to use
> > > names such as "socket-factory", "ssl-socket-factory" etc which are quite
> > > valid (even if I dislike that they no follow defacto standard). Each role
> > > name designates a component that satisfies certain constraints. In
> > > ECM/Cocoon land there is only one constraint (ie class/type of returned
> > > component) hence the rolename maps to class returned. In some containers
> > > there can be other constraints.
> >
> >Ok, this is probably a context that I'm misssing, can you elaborate more
> >on this? It would be helpful to understand your insights.
>
> Okay I will try ;)
Thanks, this makes it a lot clearer. Please, see my comments intermixed.
> Perhaps it is better to describe it in terms of a hypothetical container
> that could be created once I finish the new metainfo stuff. Consider a
> component X. Associated with that component is some metainfo and assuming
> it is a similar format to Phoenixs Blockinfo assume it has a section such as
>
> <component>
> ...
> <dependencies>
> <dependency>
> <role>my-transformer</role>
> <service classname="org.apache.cocoon.api.Transformer"/>
> <attribute name="type" value="xslt"/>
> </dependency>
> </dependencies>
> ...
> </component>
>
> This saids that X has a dependency on a component that implements interface
> org.apache.cocoon.api.Transformer, is of type "xslt" and is accessed from
> ComponentManager using the key "my-transformer". Note I have intentionally
> left "type=xslt" undefined as it is a container specific concept.
> (Alternatively you may do something like "handles-dtd=..." or whatever).
>
> <service/> + <attribute/>s == constraints on dependency
> <role/> == key used to lookup component
>
> So all the container needs to do is lookup a component with the key
> "my-transformer" and the correct component is returned.
Cocoon needs a 2-d lookup space, this is not going to change in the
future. The above doesn't give it to me unless I namespace the key:
- 'generator:file'
- 'org.apache.cocoon.generating.Generator/file'
- ???
then, what do I gain from A5?
> The process of determining the correct component is essentially what we
> have been terming "assembly" and is currently container specific (and will
> continue to be so in all likelihood).
Of course.
> * Phoenix requires that the user explicitly assemble component and make
> sure all components have their components mapped correctly etc.
Ok.
> * Merlin will auotmatically assemble the application. ie For each
> dependency it will look for potential providers among other components. If
> there is only one potential provider it will use that. If there is more
> than one potential provider then it will select one based on some heuristic
> (it uses a "policy" (aka "hint") attribute).
Ok, great. So, what's wrong with
lookup(role, policy)
?
> * ECM does not separate out assembly and development stages. Effectively
> you hardwire the assembly information into the components when you supply
> interface name + "hint"
This is the hack I'm referring to when I see ROLE + "/hint" and I
totally agree with you that this is bad.
*STILL* I need a way to suggest the container a specific lookup policy
(strategy, methodology, philosophy, call it as you like! but we *NEED*
that information separate from the role)
Look: because Phoenix doesn't need it, it doesn't mean that the rest of
the world doesn't need it.
Moreover, you are explicitly stating that other containers (Merlin) need
that, so what's the damn problem with a 2-d lookup mechanism?
> * Fortress is currently similar to ECM but Leo plans to fix it so that it
> is possible to to assemble component outside code (whether he chooses
> Merlin or Fortresses strategy I am not sure but I believe Merlins is more
> approriate for Cocoon).
>
> So if Leo chooses to go the Merlin-esque route then there will no changes
> to current sitemap format unless you want to explicitly declare a mapping
> rather than allowing the container to auotmatically manage it.
>
> What will be changed is the presence of per component descriptors. You may
> say that these are a PITA to maintain (and they are!) so what I plan to do
> is create an XDoclet task to autogenerate them.
hmmm,
> So what you will need to do
> is add in javadoc markup to your component so that they look like the
> following.
>
> /**
> * @avalon.component lifestyle="threadsafe"
> */
> class MyComponent
> {
> /**
> * @avalon.dependency role="my-transformer" service="Transformer"
> type="xslt"
> */
> void compose(ComponentManager cm)
> {
> m_myDependency = (Transformer)cm.lookup( "my-transformer" );
> }
> }
>
> Note the above would produce a descriptorsimilar to the one I outlined
> above. However in cases where you follow the convention and the lookup key
> is the same as the interface name you can get away with even less markup so
> that it just looks like
>
> /**
> * @avalon.dependency service="Transformer" type="xslt"
> */
> void compose(ComponentManager cm)
> {
> m_myDependency = (Transformer)cm.lookup( Transformer.ROLE );
> }
>
> An architecture like the above is soooooo much easier to maintain than the
> current ECM which has a global namespace and treats the ComponentManager as
> a Container. It will also allow much more flexability in future and is more
> maintainable.
Know what? I tend to agree with this. The need for all those
class="org.apache.*" stuff in XML files bothered me a lot. Placing them
in a XDoclet type wrapper makes a lot of sense, even if it won't be easy
to make the cocoon-dev community buy that.
> Given an architecture like this there is no longer any need for a second
> hint parameter in ComponentManager.lookup() method.
But I can't see this. Sorry, please, be patient.
> It would also allow all
> the containers to share components which is currently not possible due to
> differences in way we specify metadata.
>
> Does that make it any clearer?
Yes, I like what I see conceptually, but I don't see, from what I
understood, why you feel that a 2-d lookup space (role,policy) is bad.
> The key points are;
>
> * separating the lookup key for dependency from set of constraints
> associated with dependency
Absolutely, I agree they should be decoupled, this is exactly why I
liked the 2-d lookup approach where one dimension connected with the
dependency and another one to the constraints associated with the
dependency.
> * simplifying interface from user perspective and making it harder to abuse
> the
> * separating out separate stages/views (ie assembler vs develoepr view).
> * easing product evolution
These are highly subjective and I won't question them.
Like I said, I like what I see, but I fail to see why a 2-d lookup space
is a bad thing, even with the context you give me.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
