Nicola Ken Barozzi wrote:
>
> Stephen McConnell wrote:
>
>>
>>
>> Nicola Ken Barozzi wrote:
>>
>>>
>>> Nicola Ken Barozzi wrote:
>>>
>>>>
>>>> [EMAIL PROTECTED] wrote:
>>>>
>>>>> donaldp 2002/09/06 02:42:35
>>>>>
>>>> ...
>>>>
>>>>> Log:
>>>>> Implement BlockContext.getResourceAsStream() so that a block is
>>>>> capable of
>>>>> locating resources in the sar file. This method will retrieve
>>>>> the resource
>>>>> regardless of where it is located.
>>>>> This allows blocks to aquire resources regardless of where
>>>>> they are located;
>>>>> * in base directory
>>>>> * in work directory
>>>>> * in .sar file (in future)
>>>>> * in some vfs (in future)
>>>>
>>>>
>>>>
>>>> This is a non-standard implementation of a Context...
>>>>
>>>> -1 *if* Blocks must aquire it using a cast, because it makes them
>>>> unnecessarily dependent on Phoenix. Unnecessarily since this is a
>>>> general
>>>> concept.
>>>>
>>>> This can be done also as a Service, so it gets inserted as a
>>>> dependency; if it must stay in the Context, it should be gotten
>>>> from the context via a key that is declared in xinfo (I propose it
>>>> to be standard).
>>>
>>>
>>> I really didn't mean to veto formally, just regard this as an
>>> opinion on how it could also be done...
>>>
>>
>> In which case I'll veto this formally.
>>
>> -1 to the addition of BlockContext.getResourceAsStream()
>
>
> Stephen, I have been thinking about this today, and I looked at mail
> archives and at other widely used Contexts (ServletContext), and came
> to the conclusion that it's not an issue.
>
> What we both think is bad, it to have to cast a Context to a specific
> Context instance, which sounds as bad as casting a ServiceManager to a
> specific ServiceManager.
>
> Why?
> Because it's not declared in the descriptor.
Yep.
>
> Solution: declare it! ;-)
Exactly.
>
>
> Simply declare it, and the problem will vanish, since having
> dependencies to a Context or to the objecs in the Context is
> equivalent, there is just a further deferencing level, but the
> dependency is still there, you cannot remove it.
>
> Also, think of how other context are, they are like the BlockContext,
> and this is how users want it.
>
> For example, i was quite confused by the deferencing that the Cocoon
> Context does; to use the objectmodel methods I have to get the
> Context, then get the objectmodel from it, and then call some method!
>
> Honestly I now think that it's better for some cases that the users to
> have the context be declared as a dependency itself.
>
I completely agree.
Context is no less a dependency condition that a service dependency -
they are handled differently (a service depedency reference a component
that may have dependencies, etc. whereas a context depedency is a
dependecy on an java.lang.Object or derived type). This issue here is
"declaration" which I think is comming sometime soon. Based on the
updates on the CVS to seperate a release Phoenix from ongoping
development I'm happy to withdraw my -1s because I'm confident that we
will see declaration of context criteria inside Phoenix in the near
future. Assuming extensions are put in place such that they respect the
underlying context rules (i.e. access to an typed object via a key -
then we will not have a problem or at least reduce the scope of the
problem to identifed non-portable component types).
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]>
