This context is a map containing key value pairs, it contains some "global" information (paths etc.) and e.g. the object model. So even if we would move away from avalon we could have this map without breaking compatibility here. That's why I'm against "avalonContext". We already have cocoon.context, couldn't we make things available from there?
Carsten > -----Original Message----- > From: Sylvain Wallez [mailto:[EMAIL PROTECTED] > Sent: Monday, June 14, 2004 2:47 PM > To: [EMAIL PROTECTED] > Subject: Re: [VOTE] Unrestricting the FOM > > Carsten Ziegeler wrote: > > >Sylvain Wallez wrote: > > > > > >>- [ ] to remove restrictions on existing objects. > >> > >> > >+1 > > > > > >>- [ ] to add cocoon.avalonContext. > >> > >> > > > >-1 for the name "avalonContext". I think we should avoid > references to Avalon whereever possible. Otherwise perhaps we > have to rename it in the future. > >So, +1 if a different name is used. > > > > > > Well, how to name it since this *is* the Avalon context? I > mean if one day we totally move away from Avalon, that object > will naturally disappear. With some back compatibility > problems, of course, but there will also be many others in > many other places in our code. > > Or something like "frameworkContext" or "containerContext"? > Sure, it avoids the Avalon name but IMO doesn't clearly > indicate what it is about. > > Sylvain > > -- > Sylvain Wallez Anyware Technologies > http://www.apache.org/~sylvain http://www.anyware-tech.com > { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects } > >
