Igor Fedorenko wrote:
>
>
> Nicola Ken Barozzi wrote:
>
>>
>> Igor Fedorenko wrote:
>>
>>>>> Possibly it could be per-application, per-component, per-service
>>>>> or even per "client".
>>>>
>>>>
>>>>
>>> Is there a concept of a client in phoenix at the moment? I'd like
>>> not to consider per-client interceptors, at least for now.
>>
>>
>> +1 ATM
>
> Excuse my ignorance, but what "ATM" stands for?
>
>>> Blocks must not know anything about their interceptors, so blocks do
>>> not depend on interceptors. Interceptors on other hand most likely
>>> depend on blocks they intercept. For example, jaas interceptor I am
>>> working on needs access to block metadata.
>>
>>
>>
>> Yes, I agree.
>> But... (see next example)
>>
>>> I am not sure if interceptors need access to block state though.
>>
>>
>>
>> Block state?
>> You mean the Context?
>
> No, I meant hard data stored inside component instance.
>
>> Most probably yes. Think of an authentication interceptor; it must be
>> able to see the info on the request, which also the block needs to see.
>> The fact is that both the interceptor and the block need to have
>> specified the keys they will use.
>> Does this tie the two together somewhat, also the other way around?
>
> I agree, that Context as a common place for all sorts of context
> parameters sounds cool, but there is no way to add something into a
> Context.
Addition of something into a context is possible:
Map map = new Hashtable();
DefaultContext newContext = new DefaultContext( map, oldContext );
// do anything you want with the map
// then seal the context
newContext.makeReadOnly();
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]>
