Nicola Ken Barozzi wrote:
>
> Stephen McConnell wrote:
>
>>
>>
>>>> Nicola Ken Barozzi wrote:
>>>>
>>>>> How can we make an Object be sure that it's being treated by an
>>>>> Avalon container?
>>>>
>>>>
>>>> we cannot (in a way expressed in java code). Is there a need?
>>>
>>>
>>> Definately, IMNSHO.
>>> I've seen many users start Avalon Components with new, and wait to see
>>> the Avalon interface methods called :-O
>>>
>>> If the component isn't created in a container, it woud be cool if it
>>> could barf.
>>>
>>> <attention mode="heretic">
>>> Component interface as a teg interface is useless and in some cases
>>> bad for reasons already expressed.
>>> But maybe we could make an abstrace SafeService that can act as a
>>> base class to extend to make a Service that can be created only by a
>>> container: private method, creator method and check of proper order
>>> of interface calling.
>>> </attention>
>>
>>
>> *eeek* - drop the capatilized Container and I'm with you.
>
>
> container (it's what I meant ;-)
>
> > A component is
>
>> described in terms of interfaces and lifecycle semantics that are
>> managed by an implementation. We tend to refer to the
>> imnplementation as a container because this makes sence in the
>> overall pattern of usage. What you really need to rugged testing in
>> the contents you make public to make sure that usage outside of a
>> managed context results in quick failure. This is also one of the
>> prime objectives of Merlin - a mechanisms to do exacly what your
>> user's want to do - just run the component.
>
>
> I want the object to complain if its lifecycle methods are called in
> the wrong order or not called before other things.
> Basically checking that it's being created by an external controller
> entity that is not simply new().
>
>
>>>>>>>> 5) addition of an _optional_ lookup() method that supports
>>>>>>>> hints, to
>>>>>>>> enable smooth migration from ComponentSelector usage
>>>>>>>
>>>>>>>
>>>>>>> -1s
>>>>>>
>>>>>>
>>>>>> From a pure framework perspective I'm totally in agreement with
>>>>>> the above (irrespective of the pain and suffering I'm enduring
>>>>>> with respect to the metainfo/metadata issues inflicted by an
>>>>>> unmentionable "Australia" personality). However, if we take into
>>>>>> account ECM and the interest in facilitating a smooth migration
>>>>>> path, I see only two alternative; either we provide a lookup(
>>>>>> role, hint) in the framework (which I dislike in terms of the
>>>>>> curent form being dicusssed), or (b) an extended CM is defintion
>>>>>> at the excalibur level that provide a bridge from ECM to the
>>>>>> emerging container models.
>>>>>
> >>>>
>
>>>>> Now, this thing of /hints/ got me thinking.
>>>>>
>>>>> As I said previously, it seems that:
>>>>>
>>>>> Role: what
>>>>> Hint: how
>>>>
>>>>
>>>> ...
>>>>
>>>>
>>>>> ROLE: what it should do
>>>>> CHARACTERIZATION: how it should do it
>>>>> PREFERRED ACTOR: hint about *who* should do it
>>>>
>>>>
>>>> nope.
>>>>
>>>> The role determines what part a component plays in your
>>>> application; it
>>>> is perfectly valid for the role to include information on the "how".
>>>>
>>>> Tight coupling of role to interface name is merely a convenience (it
>>>> allows us to get away with easy casts).
>>>
> >>
>
>>> I'm not so sure.
>>> What do the Connection and SSLConnection components do?
>>> Make a connection.
>>> They use the same interfaces.
>>>
>>> I should be able to say that I just need to make a connection or
>>> that I need to make a *certain* type of connection.
>>>
>>> If we say that SSLConnection is a role itself, it will not be given me.
>>>
>>> The fact is that sometimes I want the container to decide for me,
>>> sometimes I don't.
>>> When the container decides, I just specify a role.
>>> When I decide, I also specify a sub-role.
>>>
>>>>> Well, this shows that hints are really not needed.
>>>>
>>>>
>>>> yup. Except we have to take into account an already existing CS.
>>>
>>>
>>> That use a hint as a sub-role usually.
>>>
>>>>> The point is that we need a sub-role.
>>>>> An interface (Role), tells me what to do, but does not specify how
>>>>> it should be done.
>>>>> This is not something that can be forgotten, as in the SSL case.
>>>>>
>>>>> I would deprecate hints in favor of sub-roles (or call them in a
>>>>> better way, I'm no ace in names ;-)
>>>>
>>>>
>>>> strings are pretty free-form. It is easy to describe both a role "king
>>>> of all England" and a sub-role "mad" in a single string: "mad king of
>>>> all England".
>>>
>>>
>>> This is an implementation detail.
>>> Or you do Role,SubRole or "role/subrole".
>>> It's not a problem, but semantically there is a point in defining
>>> role and subrole.
>>>
>>
>> Role is simply a key that is unique within the scope of the CM/SM
>> that is supplied to a component. Any semantics beyond that imply
>> that your component has a private arrangement with its container in
>> that the semantics of the lookup interface are modified by the
>> introduction of dark-magic ... which means its not a portable component.
>
>
> Hmmm, I mean that simply using a unique key is not enough.
> In sentences, I want subjects (the container), verbs (the ROLE) and
> other stuff that specializes (sub-role).
>
> I need hierarchy, with the ability of stopping at a more generic level
> (do it!) or going in more detail (do it with SSL!).
>
No problem - you define a component with service interface that
understands these notions and you declare this as a dependecy of the
component that needs this level of selection functionality. The CM/SM
default implementations will provide it to you. Take a look at the
DefaultServiceManager and DefaultComponentManager code and you will see
that role argument is simply applied as a key in a table, and if not
found passed to the parent manager or an exception is thrown. I.e. no
magic - no interpritation of the role argument.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
