You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Steve Flasby <st...@flasby.org> on 2009/05/05 09:15:08 UTC
Like to override normal page mapping but setResponsePage(...) is
final
Chaps,
We have a requirement to customize certain pages depending on the
installation. My approach is to subclass the pages needing customization
and put the difference in the subclass. Then a bit of installation
specific config overrides the normal destination page and returns a
different one.
This seems an OK approach (other approaches happily received) but
requires that I be able to intercept calls to the original page with
calls to the subclassed version.
I was going to implement a subclass of RequestCycle to lookup the requested
page and use the subclass if my configuration specifies one. That way there
is no change needed in the rest of the application when we decide to use
a modified page.
new WebRequestCycle(this, (WebRequest)request, (WebResponse)response){
public <C extends Page> void setResponsePage(final Class<C> pageClass, final PageParameters pageParameters,
final String pageMapName) {
// finds configured alternative or returns same pageClass if nothing
// configured for this page.
Class<C> altClass = getPageFactory().getPage(pageClass);
super.setResponsePage( altClass, pageParameters, pageMapName);
}
};
Unfortunately, setResponsePage(...) is final so I cant. This makes
me think I am approaching this wrong as whenever I find I am blocked
doing something in Wicket it's usually because I am going the wrong way.
I'm using 1.4RC2.
Can anyone offer an alternative for me please.
Cheers - Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Like to override normal page mapping but setResponsePage(...)
is final
Posted by Steve Flasby <st...@flasby.org>.
Mmm, you are right.
One of my complaints about gadgets like Spring is that it does things by
magic configured somewhere in an XML wonderland. It's better to keep it
explicit. I will shut up now.
Thanks, Igor.
Cheers - Steve
Igor Vaynberg wrote:
> it is final because we like to keep internals locked up so we can
> easily change them even during minor version upgrades. if we make the
> method overridable we are defining a certain contract which we do not
> want to support.
>
> to you it may seem like a shame, but people who read your code will
> probably think otherwise as they will not be left wondering why they
> are seeing a different page. a matter of taste i suppose.
>
> -igor
>
> On Tue, May 5, 2009 at 11:50 PM, Steve Flasby <st...@flasby.org> wrote:
>> Hi Igor, thanks.
>> Yeah, there is no other choice given the final methods. A bit of a shame
>> really, as having this work uniformly will depend on us all remembering
>> to do this instead of simply calling setResponse() directly.
>>
>> Just out of interest, does anyone know why this method is final?
>>
>>
>> Cheers - Steve
>>
>>
>> Igor Vaynberg wrote:
>>> setResponsePage(MyApplicaton.getCustomizedPageXClass(), .., ..)
>>>
>>> -igor
>>>
>>> On Tue, May 5, 2009 at 12:15 AM, Steve Flasby <st...@flasby.org> wrote:
>>>> Chaps,
>>>> We have a requirement to customize certain pages depending on the
>>>> installation. My approach is to subclass the pages needing customization
>>>> and put the difference in the subclass. Then a bit of installation
>>>> specific config overrides the normal destination page and returns a
>>>> different one.
>>>>
>>>> This seems an OK approach (other approaches happily received) but
>>>> requires that I be able to intercept calls to the original page with
>>>> calls to the subclassed version.
>>>> I was going to implement a subclass of RequestCycle to lookup the
>>>> requested
>>>> page and use the subclass if my configuration specifies one. That way
>>>> there
>>>> is no change needed in the rest of the application when we decide to use
>>>> a modified page.
>>>>
>>>> new WebRequestCycle(this, (WebRequest)request, (WebResponse)response){
>>>> public <C extends Page> void setResponsePage(final Class<C> pageClass,
>>>> final PageParameters pageParameters,
>>>> final String pageMapName) {
>>>> // finds configured alternative or returns same pageClass if nothing
>>>> // configured for this page.
>>>> Class<C> altClass = getPageFactory().getPage(pageClass);
>>>> super.setResponsePage( altClass, pageParameters, pageMapName);
>>>> }
>>>> };
>>>>
>>>> Unfortunately, setResponsePage(...) is final so I cant. This makes
>>>> me think I am approaching this wrong as whenever I find I am blocked
>>>> doing something in Wicket it's usually because I am going the wrong way.
>>>>
>>>> I'm using 1.4RC2.
>>>>
>>>> Can anyone offer an alternative for me please.
>>>>
>>>>
>>>> Cheers - Steve
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Like to override normal page mapping but setResponsePage(...) is
final
Posted by Igor Vaynberg <ig...@gmail.com>.
it is final because we like to keep internals locked up so we can
easily change them even during minor version upgrades. if we make the
method overridable we are defining a certain contract which we do not
want to support.
to you it may seem like a shame, but people who read your code will
probably think otherwise as they will not be left wondering why they
are seeing a different page. a matter of taste i suppose.
-igor
On Tue, May 5, 2009 at 11:50 PM, Steve Flasby <st...@flasby.org> wrote:
> Hi Igor, thanks.
> Yeah, there is no other choice given the final methods. A bit of a shame
> really, as having this work uniformly will depend on us all remembering
> to do this instead of simply calling setResponse() directly.
>
> Just out of interest, does anyone know why this method is final?
>
>
> Cheers - Steve
>
>
> Igor Vaynberg wrote:
>>
>> setResponsePage(MyApplicaton.getCustomizedPageXClass(), .., ..)
>>
>> -igor
>>
>> On Tue, May 5, 2009 at 12:15 AM, Steve Flasby <st...@flasby.org> wrote:
>>>
>>> Chaps,
>>> We have a requirement to customize certain pages depending on the
>>> installation. My approach is to subclass the pages needing customization
>>> and put the difference in the subclass. Then a bit of installation
>>> specific config overrides the normal destination page and returns a
>>> different one.
>>>
>>> This seems an OK approach (other approaches happily received) but
>>> requires that I be able to intercept calls to the original page with
>>> calls to the subclassed version.
>>> I was going to implement a subclass of RequestCycle to lookup the
>>> requested
>>> page and use the subclass if my configuration specifies one. That way
>>> there
>>> is no change needed in the rest of the application when we decide to use
>>> a modified page.
>>>
>>> new WebRequestCycle(this, (WebRequest)request, (WebResponse)response){
>>> public <C extends Page> void setResponsePage(final Class<C> pageClass,
>>> final PageParameters pageParameters,
>>> final String pageMapName) {
>>> // finds configured alternative or returns same pageClass if nothing
>>> // configured for this page.
>>> Class<C> altClass = getPageFactory().getPage(pageClass);
>>> super.setResponsePage( altClass, pageParameters, pageMapName);
>>> }
>>> };
>>>
>>> Unfortunately, setResponsePage(...) is final so I cant. This makes
>>> me think I am approaching this wrong as whenever I find I am blocked
>>> doing something in Wicket it's usually because I am going the wrong way.
>>>
>>> I'm using 1.4RC2.
>>>
>>> Can anyone offer an alternative for me please.
>>>
>>>
>>> Cheers - Steve
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Like to override normal page mapping but setResponsePage(...)
is final
Posted by Steve Flasby <st...@flasby.org>.
Hi Igor, thanks.
Yeah, there is no other choice given the final methods. A bit of a shame
really, as having this work uniformly will depend on us all remembering
to do this instead of simply calling setResponse() directly.
Just out of interest, does anyone know why this method is final?
Cheers - Steve
Igor Vaynberg wrote:
> setResponsePage(MyApplicaton.getCustomizedPageXClass(), .., ..)
>
> -igor
>
> On Tue, May 5, 2009 at 12:15 AM, Steve Flasby <st...@flasby.org> wrote:
>> Chaps,
>> We have a requirement to customize certain pages depending on the
>> installation. My approach is to subclass the pages needing customization
>> and put the difference in the subclass. Then a bit of installation
>> specific config overrides the normal destination page and returns a
>> different one.
>>
>> This seems an OK approach (other approaches happily received) but
>> requires that I be able to intercept calls to the original page with
>> calls to the subclassed version.
>> I was going to implement a subclass of RequestCycle to lookup the requested
>> page and use the subclass if my configuration specifies one. That way there
>> is no change needed in the rest of the application when we decide to use
>> a modified page.
>>
>> new WebRequestCycle(this, (WebRequest)request, (WebResponse)response){
>> public <C extends Page> void setResponsePage(final Class<C> pageClass,
>> final PageParameters pageParameters,
>> final String pageMapName) {
>> // finds configured alternative or returns same pageClass if nothing
>> // configured for this page.
>> Class<C> altClass = getPageFactory().getPage(pageClass);
>> super.setResponsePage( altClass, pageParameters, pageMapName);
>> }
>> };
>>
>> Unfortunately, setResponsePage(...) is final so I cant. This makes
>> me think I am approaching this wrong as whenever I find I am blocked
>> doing something in Wicket it's usually because I am going the wrong way.
>>
>> I'm using 1.4RC2.
>>
>> Can anyone offer an alternative for me please.
>>
>>
>> Cheers - Steve
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Like to override normal page mapping but setResponsePage(...) is
final
Posted by Igor Vaynberg <ig...@gmail.com>.
setResponsePage(MyApplicaton.getCustomizedPageXClass(), .., ..)
-igor
On Tue, May 5, 2009 at 12:15 AM, Steve Flasby <st...@flasby.org> wrote:
> Chaps,
> We have a requirement to customize certain pages depending on the
> installation. My approach is to subclass the pages needing customization
> and put the difference in the subclass. Then a bit of installation
> specific config overrides the normal destination page and returns a
> different one.
>
> This seems an OK approach (other approaches happily received) but
> requires that I be able to intercept calls to the original page with
> calls to the subclassed version.
> I was going to implement a subclass of RequestCycle to lookup the requested
> page and use the subclass if my configuration specifies one. That way there
> is no change needed in the rest of the application when we decide to use
> a modified page.
>
> new WebRequestCycle(this, (WebRequest)request, (WebResponse)response){
> public <C extends Page> void setResponsePage(final Class<C> pageClass,
> final PageParameters pageParameters,
> final String pageMapName) {
> // finds configured alternative or returns same pageClass if nothing
> // configured for this page.
> Class<C> altClass = getPageFactory().getPage(pageClass);
> super.setResponsePage( altClass, pageParameters, pageMapName);
> }
> };
>
> Unfortunately, setResponsePage(...) is final so I cant. This makes
> me think I am approaching this wrong as whenever I find I am blocked
> doing something in Wicket it's usually because I am going the wrong way.
>
> I'm using 1.4RC2.
>
> Can anyone offer an alternative for me please.
>
>
> Cheers - Steve
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org