Sylvain Wallez wrote:
>
> +1. If we can solve the problem outlined by Carsten
> (SitemapSystemContext that wraps the SystemContext and overrides
> resove() ?), this will allow uniform access to input sources from
> everywhere, instead of using URLFactories when a SourceResolver isn't
> available.
See my response to Carsten. I would prefer moving it to the
RequestContext.
> A question about get() : is it a shortcut for
> getEnvironmentContext().get(), or does the SystemContext hold additional
> values, and if so, which ones ?
No, it is not a shortcut. The SystemContext extends the Avalon Context
object. The get() here is the one from the Context interface. It is used
for the values you get through the Contextualizable.contextualize() method.
Note that it is read only for a reason....
> > The other Context woudl be the RequestContext. That API would be like this:
> >
> > public interface RequestContext extends Map {
> > Request getRequest();
> > Session getSession();
> > Session getSession(boolean forceNew);
> > Response getResponse();
> > void redirect(String uri); // throws IllegalStateException if called after
>generator setup.
> > Object get(Object key); // from Map
> > void put(Object key, Object value); // from Map
> > }
> >
> > This makes the RequestContext compatible with ObjectModel as it stands now--
> > not forcing any MAJOR changes to the API. It also removes the need of exposing
> > the Redirector interface to the clients as a passed argument. While it may
> > seem tempting to do so, most developers will get the clue very quickly that
> > it can only be done from the SetUp method. This will expose it to be used to
> > generators and transformers alike, but the distinct difference is that the
> > setup and generate commands are separate.
>
> Extending Map is a good idea : only the parameter type will change, so
> this will require only a recompilation without code change (provided
> that we route get(RESPONSE_OBJECT) to getResponse(), etc). But this also
> clearly states that data can be added to the object model using put().
> There has been several posts in the past giving me the impression this
> was possible, but not encouraged. Was this impression wrong ?
We have multiple issues here. The RequestContext needs to be the same (or equivalent)
object for the life of the request. This allows property passing between stages
during setup phases. Currently you have to do that through the Request interface.
If we do not want to simplify and allow the RequestContext the same object for the
life of the request, then we should extend Avalon Context which is read only.
In any regards, the RequestContext MUST protect the values in RESPONSE_OBJECT, et al.
Because we have an object that we control the code, we can safely do that now. And for
back compatibility, I would require that the RESPONSE_OBJECT and similar entries be
kept for as long as the deprecation period.
> > This also simplifies client code--and the get/put methods in the RequestContext,
> > but it also minimizes the overhead involved in looking up the specific environment
> > interfaces from a generic Map.
> >
> > You'll notice that the Environment interface is missing. That is because the
> > Environment interface has been identified as the contract between the sitemap
> > and the environment that Cocoon is living in.
> >
> > 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. This will also easy extension in the future if need : just add
> method on RequestContext, without changing the interfaces.
That was my whole idea.
> And also quoting Carsten, which version will have all this ? There are a
> number of interesting changes proposed these days, but we're also
> discussing about the 2.0 final release date.
I don't want to hold up the 2.0 release date. This should be aimed at 2.1.
> Should we release a 2.0 quickly and include these changes in 2.1 at the
> price of incompatibility, or should we put them in 2.0, even if this
> delays it a little bit ? I don't have a definite opinion about that
> since I don't have the same urge for a final version as some of you (our
> customers accept a Release Canditate if we support it).
Use deprecation. It is a tool to allow backwards compatibility, but steer
new and revamped development to the correct methods. If the deprecation lives
for at least a year, it allows a nice migration period.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
