Hey Andy, why does RequestContext need this method? Is this something
that's will change on a per-request basis? The reason I ask is that
when I start doing work with the official 301 release, RequestContext is
going to have an annotation which forces it to be re-created each render
request. The current bridge will try to save things from the previous
action request for use in the render, but the rendering context contains
some information, reguarding ppr requests, which should not stay around.
If this is not something that is able to be changed on a per request
basis then I'd prefer it being somewhere else with a large scope. If it
is something that can be changed on a per-request basis, then I agree
that the RequestContext is a good location.
Scott
Matthias Wessendorf wrote:
Hi,
On Feb 19, 2008 5:21 PM, Andy Schwartz <[EMAIL PROTECTED]> wrote:
Gang -
As part of the fix for TRINIDAD-822, I am proposing to add a new
getAccessibilityProfile() API to RequestContext (and now that I think
about it, to RenderingContext as well). Both RequestContext and
RenderingContext are abstract. In order to avoid breaking any
existing implementations out there, I was thinking that I would follow
the normal convention and add non-abstract methods with a default
implementation (return null I guess, maybe throw an assertion just to
catch some attention). However, I noticed that when we recently added
the isAnimationEnabled() methods to RequestContext/RenderingContext,
we added these as abstract methods. So I am wondering whether the
assumption is that, though these abstract base classes are technically
part of the public API, practically speaking nobody outside of
Trinidad is going to provide concrete subclasses.
So, for new API additions to RequestContext/RenderingContext -
abstract methods okay or should we be providing default
implementations?
I am fine with adding abstract methods, instead of concrete ones (yes,
that breaks things).
I also doubt, that there are tons of impls of these classes available.
-Matthias
Andy
