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-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
