Leo Sutic wrote:
>
>
>>From: Stephen McConnell [mailto:[EMAIL PROTECTED]]
>>
>>Leo Sutic wrote:
>>
>>
>>
>>>
>>>
>>>
>>>
>>>>From: Stephen McConnell [mailto:[EMAIL PROTECTED]]
>>>>
>>>>One of two things needs to happen:
>>>>
>>>>(a) either the context related constraint information is
>>>>
>>>>
>>removed from
>>
>>
>>>>ComponetInfo
>>>>
>>>>(i.e. we treat context the same way we treat configuration
>>>>and parameters - we guarantee an instance of Context and
>>>>nothing more - and document the implication of moving outside
>>>>of this constract)
>>>>
>>>>or, (b) context information is included in ComponentMetaData
>>>>
>>>>
>>>>
>>>>
>>>Stephen,
>>>
>>>context information - that is, the context entries that the
>>>
>>>
>>component
>>
>>
>>>requires should be made part of the .xinfo file and thus (b) in your
>>>list above.
>>>
>>>
>>>
>>>
>>I agree.
>>
>>
>>
>>>Reasons:
>>>
>>>1. The contract for Context specifies that it is an
>>>
>>>
>>exceptional event
>>
>>
>>> if a context entry isn't present and the component is then
>>> considered broken.
>>>
>>>2. You have to document it *somewhere*. Somehow, you must be able to
>>> take a component xinfo and see exactly what it requires to run.
>>>
>>>Number 2 is, in my opinion the most important one.
>>>
>>>
>>>
>>>
>>Without point 2 - you will never know that a component is runnable
>>without doing a lauch test and waiting for the exception to occur.
>>Without two the defintion of a portable component is a component that
>>does impliment the Contextualizable interface.
>>
>>
>>
>>>But I do not ever think you can make a context validatable. That is,
>>>even if you do include context information in the .xinfo,
>>>
>>>
>>the container
>>
>>
>>>will have no clue about what to do with it.
>>>
>>>You can constrain the context entry to the type:
>>>
>>> <context-entry key="arbetskatalog" type="java.io.File"/>
>>>
>>>But how do you tell the container that the file is supposed
>>>
>>>
>>to point at
>>
>>
>>>a context directory?
>>>
>>>
>>>
>>This is where the separation occurs between metainfo (the
>>constraints)
>>and metadata (the criteria). If we have a context constraint
>>that says
>>that the context must container an entry called "home" and that the
>>value returned shall be a java.io.File and that it contains an entry
>>called "name" and that the type is java.lang.String - I can
>>declare this
>>in an xinfo as follows:
>>
>><component-info>
>><context>
>><entry key="home" type="java.io.File"/>
>><entry key="name" type="java.lang.String"/>
>></context>
>></component-info>
>>
>>The next issue concerns the responsibility of the container to fulfil
>>that constraint. To do this a directive is needed in the component
>>desciption. For example the following information could be
>>included in a
>>application profile:
>>
>><component class="net.osm.test.MyComponent" name="test">
>> <context>
>> <entry key="name" value="Fred"/>
>> <entry key="home" class="java.io.File" value="../myHome"/>
>> </context>
>></component>
>>
>>In this simple example a single String argument is being
>>supplied. The
>>class must have a constructor that takes a single string value as a
>>parameter. For example - the case of java.io.File - it has a
>>constructor
>>that can support the above. In the case of the name (where
>>the default
>>type is String), the String class also contains a constructor with a
>>single String parameter. My experience with automated context value
>>creation is that single string parameter constructors resolved using
>>reflection solve 98% of the requirements. However, there are
>>cases when
>>you want to go further than this and provide multiple
>>parameters to the
>>class constructor.
>>
>>
>
>This would indicate that all values in the component
>context are supplied by the assembler (the person creating the
>component config).
>
>My question was regarding container-supplied context values.
>
>It would appear that context values entered as you describe
>are limited to:
>
> + constants
>
> + entered by a human
>
>Is this correct?
>
Umm, lets say that I don't agree with te question! :-)
If when you say "entered by a human" you mean that the critea for
context creation and the criteria for creation of context values must be
presented in a declarative manner - e.g. in an application profile - I
would say YES - IF, and only if the developer is writting a component
that is intended to be portable. I have cases of components that are
not intended to be portable - they are typically used inside portable
components. In these cases the parent (container) has knowlege of the
compoent types is is dealing with - typically the context creation is
done inside the java souce code - so in the context NO - context
creation is unconstrained. This is only as issue for components that
want to be independent of a particular container - and to do that the
declaration of constraints and the coreresponding creation criteria is
needed.
>
>I would then propose that we define a fixed set of context keys
>that the *container* must supply (and some that it may supply).
>
>
This is an approach I really want to avoid. What it means is that the
container is defining what is possible to the component instead of the
component defining what it needs to the container. That distinction is
really important. If we go in the direction of the container defining
what is possible - we are basically introducing an artifical limitation
into the component abstraction. Component writers will have check
documentation from different containers about the supported context keys
and types. Doing this from a componet centric declarative approach
keeps the component independent of the container which I think is a more
scalable approach.
--
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]>
