avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: Context - a future
Date Mon, 25 Nov 2002 14:01:43 GMT


One thing missing from your message is the problem statement.  I've been 
really confussed about a lot of the posts on this subject because it has 
been very unclear what peoples objective are.

As I see things, we have some fixed and imutable facts

  1. Context exists at the framework, and is not about to go away
  2. Extending the context interface has ramifications

       a) if we are providing a convinience interface only
          then this is manageable, via

           - a small number of standard context accessors
             interface enhancers that are handler by
             container implemetations

           - maintaining correspondence with get( key ) so
             that any component can fallback to the framework
             contract if it chooses to

           - supplimented by a set of recognized standard
             keys specifications

       b) if we are supplimenting context with behaviour, then
          we are dealing with both a component (client) issue
          and a container issue

           - this is an issue for a component author if the
             author wants to maintain component portability

           - this is an concern of a container author if the
             author wants to provide adaptability

       c) recognizing that there is a gray area between the
          two extremes (a) and (b) where standard context entries
          can be used to construct more sophisticated context
          implemetations (i.e. interface does not do direct
          mapping to data but behaviours are exclusively derived
          from data accessible grom get( key ) )

            - this is resolvable by following standard
              patterns on context implementation creation

 From the above - (a) is easy to do and should not disrupt anyone - (b) 
is much more about context management in general under container space 
and should be dealt with container implemetations for the time being as 
there is a lot more thinking that can go into this area.  Finally, (c) 
is easy to do simply by following the existing framework patterns 
establish for the creation of DefaultContext.  

If I understand your position correctly, I think it falls within the 
scope of (a).

In particular, if we look at cornerston components and thier depedence 
on BlockContext - we see that this depedence is actually limited to 
getWorkingDirectory() - or whatever the operation name is.  It would be 
better if we provided something like:

   * This is a convinience accessor to the standard
   * avalon context entry "avalon:work".
   interface WorkingDirectoryProvider
       File getWorkingDirectory();

The Phoenix BlockContext could be revised to the following:

   interface BlockContext extends WorkingDirectoryProvider
       // plus Phoeinix specific

This would shift cornerstone components from being depedent on Phoneix 
to being dependent on framework based interface.

Does this help? Am I correctly interpriting the problem?

Cheers, Steve.


Paul Hammant wrote:

>Can someone who is _not_ advocating any of the competing propositions for Context please
lead this
>We need a 'roll-up' on this rapidly sprawling thread.  Many people (incl me) are being
lost in the
>extensive detail.
>1) What are the competing solutions .. hashmap style get(), cast to Context derived interfaces
>2) What is the timescale we are trying aim for?  Can it go into Phoenix and Merlin or
is it a
>revolution, thus only for uber-container?
>The idea is that we get one summary of the choices.  It may be that me, Stephen, Leo(s)
>comment and the rollup is modified.  Best to leave the start of this to unaligned person
>Nicola: Can you arbitrate if too many step forward?
>PeterD: Can you post an opinion on Context?
>- Paul
>Do You Yahoo!?
>Everything you'll ever need on one web page
>from News and Sport to Email and Music Charts
>To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
>For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Stephen J. McConnell

digital products for a global economy

To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message