> Berin Loritsch wrote:
>
> Carsten Ziegeler wrote:
> >
>
> > > public interface SystemContext extends
> > > org.apache.avalon.framework.context.Context {
> > > Source resolve(String uri);
> > > org.apache.cocoon.environment.Context getEnvironmentContext();
> > > Object get(Object key); // from Avalon context
> > > }
> > >
> > > This removes the need for the SourceResolver interface to be
> > > exposed or passed
> > > as an argument to Components. Components that do not need it or
> > > use it will
> > > have access to a simpler API.
> > >
> > The intention of this interface is very good, I like it, but
> > I see one (more technical) problem here: the resolve() method
> > is Environment or Request dependant. This means, if a component
> > (e.g. the store) is contextualized at startup and gets the
> > SystemContext, the resolving of resources must be done
> > with the current environment in mind which might result in
> > different resources.
> > This resolving with respect to the current environment is
> > of course necessary for all sitemap components (generators
> > etc).
> > If we get this working: +1
>
>
> Ok, with that clarification, the resolve method would move to
> RequestContext.
>
> > What do you mean with the org.apache.cocoon.environment.Context
> > object? Is this the RequestContext mentioned below?
>
> No, that is the equivalent of the ServletContext. It is global in scope,
> and only a few components _really_ need it. If you need it, extend
> Contextualizable, and cast the Context to SystemContext.
>
Sorry, I was not very clear here:
I meant the object returned getEnvironmentContext().
> > > Lastly, this will also open up API optimizations in that we can
> > > simplify the
> > > signatures to setUp(RequestContext context, String source,
> > > Parameters params);
> > > If there is some new interface that needs to be supplied to
> the sitemap
> > > components, it will be done through the RequestContext or
> > > SystemContext objects
> > > as is appropriate.
> > >
> > +1
> >
> > What about the Interface Cookie you mentioned above? I personally would
> > like to clean up Request/Response interfaces.
> > There are certainly Environments which do not use Cookies and for
> > example don't know anything about headers. So I would like to separate
> > them from the Request/Response so that one could test if the
> > current environment supports this feature or not.
>
> Hmm. If an environment doesn't support a feature, then it should
> ignore it--in the case of headers. As to the Cookies--Cookies are
> persistent client storage. Persistent in the fact that they can last
> between sessions--not that they live forever (although sometimes it
> seems like it).
>
> In the cases where Cookies are not supported, we should follow the
> standards of how Servlets handle the case when Cookies are turned
> off. If there is no standard, we can throw a
> UnsupportedOperationException
> or something similar. It would have to extend Runtime exception
> though.
>
> If you have specific API cleanups for Request/Response, we can go through
> them as well. I was wanting to simplify the UI as much as possible
> for the HEAD branch.
>
Yes, that's great: I would like to have the minimum methods on those
interfaces as possible. That's why I thought about "outsourcing"
for example the Header stuff.
Headers are optional. An environment can of course ignore them, but
if a user of a request object calls setHeader() etc. it expects
that the header is really set.
If it can beforehand test, if headers are supported, that's for
me a cleaner solution. This test could either be done by separate
marker-like interfaces or by "supportsHeaders()" methods.
But - as Ovidiu stated recently - we should keep in mind to support
in any way most methods/features the servlet environment offers.
I will try to come up next week with a proposal for Request
and Response objects.
Carsten
>
> > By the way: About what timeframe and version are we talking here?
>
>
> These are changes to HEAD. It should be done sooner than later so we
> don't forget about them. But it is good for Cocoon 2.1. The arrangement
> allows use to simply deprecate the unused methods and point users to
> the real implementation. The deprecated methods should live for at least
> a year--that way as projects naturally upgrade, they can move to the
> new API. With the LogKit, we found that 5.5 months was not long enough
> for projects to migrate.
>
> P.S. This should not delay Cocoon 2.0 final.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
