You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Andy Schwartz <an...@gmail.com> on 2008/02/19 17:21:45 UTC
[Trinidad] Adding new methods to RenderingContext/RequestContext - abstract or not?
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?
Andy
Re: [Trinidad] Adding new methods to RenderingContext/RequestContext - abstract or not?
Posted by Andy Schwartz <an...@gmail.com>.
Thanks Matthias. Just wanted to make sure people were cool with this
approach. If anyone has concerns, please let us know.
Andy
Re: [Trinidad] Adding new methods to RenderingContext/RequestContext
- abstract or not?
Posted by Scott O'Bryan <da...@gmail.com>.
Yeah, I agree. I *think* it's actually the rendering context that is
going to be the volitile object. In either case, I guess we can broach
this subject when I actually get to researching this stuff and I'm sure
the API will not prevent us from coming up with something that performs
well.
Scott
Andy Schwartz wrote:
> Hey Scott -
>
> On Feb 19, 2008 2:11 PM, Scott O'Bryan <da...@gmail.com> wrote:
>
>> Hey Andy, why does RequestContext need this method? Is this something
>> that's will change on a per-request basis?
>>
>
> The plan is for the accessibility "profile" to be a sibling to the
> existing RequestContext accessibility "mode" and to follow the same
> lifecycle - ie. parsed from trinidad-config into the
> RequestContextBean, then exposed via the RequestContext, and promoted
> up to the RenderingContext for ease of use. I believe that this is
> the same lifecycle that is used for all of the trinidad-config
> properties (eg. see the recently added animation-enabled property). I
> would feel uncomfortable implementing a specialized solution specific
> to accessibility-profile. If we need to implement a new strategy for
> how we surface our trinidad-config properties, I would prefer that we
> tackle that generically rather than in the context of the
> accessibility profile feature. Does that sounds reasonable?
>
> Andy
>
Re: [Trinidad] Adding new methods to RenderingContext/RequestContext - abstract or not?
Posted by Andy Schwartz <an...@gmail.com>.
Hey Scott -
On Feb 19, 2008 2:11 PM, Scott O'Bryan <da...@gmail.com> wrote:
> Hey Andy, why does RequestContext need this method? Is this something
> that's will change on a per-request basis?
The plan is for the accessibility "profile" to be a sibling to the
existing RequestContext accessibility "mode" and to follow the same
lifecycle - ie. parsed from trinidad-config into the
RequestContextBean, then exposed via the RequestContext, and promoted
up to the RenderingContext for ease of use. I believe that this is
the same lifecycle that is used for all of the trinidad-config
properties (eg. see the recently added animation-enabled property). I
would feel uncomfortable implementing a specialized solution specific
to accessibility-profile. If we need to implement a new strategy for
how we surface our trinidad-config properties, I would prefer that we
tackle that generically rather than in the context of the
accessibility profile feature. Does that sounds reasonable?
Andy
Re: [Trinidad] Adding new methods to RenderingContext/RequestContext
- abstract or not?
Posted by Scott O'Bryan <da...@gmail.com>.
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 <an...@gmail.com> 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
>>
>>
>
>
>
>
Re: [Trinidad] Adding new methods to RenderingContext/RequestContext - abstract or not?
Posted by Matthias Wessendorf <ma...@apache.org>.
Hi,
On Feb 19, 2008 5:21 PM, Andy Schwartz <an...@gmail.com> 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
>
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
Re: [Trinidad] Adding new methods to RenderingContext/RequestContext -
abstract or not?
Posted by Ed Burns <Ed...@Sun.COM>.
>>>>> On Tue, 19 Feb 2008 11:21:45 -0500, Andy Schwartz <an...@gmail.com> said:
AS> Gang -
AS> As part of the fix for TRINIDAD-822, I am proposing to add a new
AS> getAccessibilityProfile() API to RequestContext (and now that I think
AS> about it, to RenderingContext as well). Both RequestContext and
It's great to see such continuing activity from you Andy.
Ed