Re: Force page reload/re-render
if(userSetWasChanged){
target.appendJavascript(window.location.reload());
or
setResponsePage(getPage());
or
setResponsePage(getPage().getClass());
}
On Tue, Nov 10, 2009 at 5:19 AM, pieter claassen
pieter.claas...@gmail.comwrote:
I have a link on a panel that is included in many pages. When the user
clicks on the link, I change something in the user settings that will
affect what gets displayed on the page. However, for that to work, I
need to reload the page after the user clicked on the link as by
default the other components that now need to be checked for
conditional visibility don't re-render (why not?). setResponsePage()
requires me to pass into the panel a target page and this becomes
complex when you have a mix of statefull and stateless pages as
targets (and it just doesn't feel right).
I am sure there must be an easier way to just re-render a page?
Any tips?
Thanks,
pieter
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
Pedro Henrique Oliveira dos Santos
Re: Force page reload/re-render
Hi Pedro,
I tried setResponsePage(getPage()) but the problem is it does not
re-render controls on the page.
setResponsePage(getPage().getClass()) only works for stateless pages
and on most of my pages, I pass params via the constructor.
The javascript option will be a last resort, but it seems to be not
the most elegant solution.
Rgds,
On Tue, Nov 10, 2009 at 11:45 AM, Pedro Santos pedros...@gmail.com wrote:
if(userSetWasChanged){
target.appendJavascript(window.location.reload());
or
setResponsePage(getPage());
or
setResponsePage(getPage().getClass());
}
On Tue, Nov 10, 2009 at 5:19 AM, pieter claassen pieter.claas...@gmail.com
wrote:
I have a link on a panel that is included in many pages. When the user
clicks on the link, I change something in the user settings that will
affect what gets displayed on the page. However, for that to work, I
need to reload the page after the user clicked on the link as by
default the other components that now need to be checked for
conditional visibility don't re-render (why not?). setResponsePage()
requires me to pass into the panel a target page and this becomes
complex when you have a mix of statefull and stateless pages as
targets (and it just doesn't feel right).
I am sure there must be an easier way to just re-render a page?
Any tips?
Thanks,
pieter
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
Pedro Henrique Oliveira dos Santos
--
Pieter Claassen
musmato.com
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Force page reload/re-render
Isn't AJAX refresh an option to consider here? For instance, defining some contexts which need to be re-rendered (e.g. marking them with an interface) and them having and IVisitor that collects all those contexts and add them to the AjaxRequestTarget? Best, Ernesto On Tue, Nov 10, 2009 at 8:19 AM, pieter claassen pieter.claas...@gmail.comwrote: I have a link on a panel that is included in many pages. When the user clicks on the link, I change something in the user settings that will affect what gets displayed on the page. However, for that to work, I need to reload the page after the user clicked on the link as by default the other components that now need to be checked for conditional visibility don't re-render (why not?). setResponsePage() requires me to pass into the panel a target page and this becomes complex when you have a mix of statefull and stateless pages as targets (and it just doesn't feel right). I am sure there must be an easier way to just re-render a page? Any tips? Thanks, pieter - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Force page reload/re-render
Both of the suggestions I think requires me to modify the logic of the
controls (either to keep track of which ones need to be updated or by
placing the rendering logic in onBeforeRender()). I think this is a
lot of work for something relative straight forward and also any
changes to permission structures and I have to modify controls.
Is there no way that I can mark a page obtained via getPage() as
requiring re-rendering? I tried getPage().dirty() before the
setResponsePage() but that didn't do anything.
Thanks for the feedback though.
P
On Tue, Nov 10, 2009 at 1:10 PM, Pedro Santos pedros...@gmail.com wrote:
I tried setResponsePage(getPage()) but the problem is it does not
re-render controls on the page.
Where do you implement your control ( update logic )? Consider do it
overriding Component.onBeforeRender method
On Tue, Nov 10, 2009 at 10:03 AM, pieter claassen
pieter.claas...@gmail.com wrote:
Hi Pedro,
I tried setResponsePage(getPage()) but the problem is it does not
re-render controls on the page.
setResponsePage(getPage().getClass()) only works for stateless pages
and on most of my pages, I pass params via the constructor.
The javascript option will be a last resort, but it seems to be not
the most elegant solution.
Rgds,
On Tue, Nov 10, 2009 at 11:45 AM, Pedro Santos pedros...@gmail.com
wrote:
if(userSetWasChanged){
target.appendJavascript(window.location.reload());
or
setResponsePage(getPage());
or
setResponsePage(getPage().getClass());
}
On Tue, Nov 10, 2009 at 5:19 AM, pieter claassen
pieter.claas...@gmail.com
wrote:
I have a link on a panel that is included in many pages. When the user
clicks on the link, I change something in the user settings that will
affect what gets displayed on the page. However, for that to work, I
need to reload the page after the user clicked on the link as by
default the other components that now need to be checked for
conditional visibility don't re-render (why not?). setResponsePage()
requires me to pass into the panel a target page and this becomes
complex when you have a mix of statefull and stateless pages as
targets (and it just doesn't feel right).
I am sure there must be an easier way to just re-render a page?
Any tips?
Thanks,
pieter
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
Pedro Henrique Oliveira dos Santos
--
Pieter Claassen
musmato.com
--
Pedro Henrique Oliveira dos Santos
--
Pieter Claassen
musmato.com
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Force page reload/re-render
Hi Ernesto,
To recap, I have a control panel visible on each and every page and in
that control panel, you can select the appropriate role you want to
use. Based on that role some menu items will be visible or not
(example below is correct). I am sure this problem has been solved
before :-0 as this is a very normal usecase for context sensitive
navigation.
It seems that there is no way to force the page to re-render using getPage()?
Thanks for the feedback so far. I keep on coming up against this issue
and have not found a reasonable solution to the problem. The
javascript option seems to be best so far.
Pieter
On Tue, Nov 10, 2009 at 1:41 PM, Ernesto Reinaldo Barreiro
reier...@gmail.com wrote:
Even if you re-render your page components that are not dynamic will not
change their state: unless you create a new instance of the page, I guess.
By this I mean.
class MyPanel {
public MyPanel(id) {
PanelB panelB = new Panel(B);
panelB.setVisible(getSomeCondition());
}
}
Even if condition getSomeCondition() change, and you re-render MyPanel, or
the whole page, panelB will still be not visible. So, if you want something
to be dynamic you have to program it to be dynamic.
Best,
Ernesto
On Tue, Nov 10, 2009 at 1:20 PM, pieter claassen pieter.claas...@gmail.com
wrote:
Both of the suggestions I think requires me to modify the logic of the
controls (either to keep track of which ones need to be updated or by
placing the rendering logic in onBeforeRender()). I think this is a
lot of work for something relative straight forward and also any
changes to permission structures and I have to modify controls.
Is there no way that I can mark a page obtained via getPage() as
requiring re-rendering? I tried getPage().dirty() before the
setResponsePage() but that didn't do anything.
Thanks for the feedback though.
P
On Tue, Nov 10, 2009 at 1:10 PM, Pedro Santos pedros...@gmail.com wrote:
I tried setResponsePage(getPage()) but the problem is it does not
re-render controls on the page.
Where do you implement your control ( update logic )? Consider do it
overriding Component.onBeforeRender method
On Tue, Nov 10, 2009 at 10:03 AM, pieter claassen
pieter.claas...@gmail.com wrote:
Hi Pedro,
I tried setResponsePage(getPage()) but the problem is it does not
re-render controls on the page.
setResponsePage(getPage().getClass()) only works for stateless pages
and on most of my pages, I pass params via the constructor.
The javascript option will be a last resort, but it seems to be not
the most elegant solution.
Rgds,
On Tue, Nov 10, 2009 at 11:45 AM, Pedro Santos pedros...@gmail.com
wrote:
if(userSetWasChanged){
target.appendJavascript(window.location.reload());
or
setResponsePage(getPage());
or
setResponsePage(getPage().getClass());
}
On Tue, Nov 10, 2009 at 5:19 AM, pieter claassen
pieter.claas...@gmail.com
wrote:
I have a link on a panel that is included in many pages. When the
user
clicks on the link, I change something in the user settings that
will
affect what gets displayed on the page. However, for that to work, I
need to reload the page after the user clicked on the link as by
default the other components that now need to be checked for
conditional visibility don't re-render (why not?). setResponsePage()
requires me to pass into the panel a target page and this becomes
complex when you have a mix of statefull and stateless pages as
targets (and it just doesn't feel right).
I am sure there must be an easier way to just re-render a page?
Any tips?
Thanks,
pieter
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
Pedro Henrique Oliveira dos Santos
--
Pieter Claassen
musmato.com
--
Pedro Henrique Oliveira dos Santos
--
Pieter Claassen
musmato.com
--
Pieter Claassen
musmato.com
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Force page reload/re-render
Hi Pieter
Due to the Java-Nature of Wicket, things done in the constructor are
only executed once for this instance. Since F5 only re-renders the
instance, the expression setVisible(whatever()) is only executed once.
The most dynamic implementation would be to override isVisible() for
every component that changes its visibility dynamically or if that would
lead to lots of code duplication, you could write a behaviour doing
exactly that and add it to every component (or container) as needed.
isVisible() is evaluated during each and every rendering phase, meaning
upon every F5 reload as well.
This is the way we do it for dynamic content.
Matt
pieter claassen wrote:
Hi Ernesto,
To recap, I have a control panel visible on each and every page and in
that control panel, you can select the appropriate role you want to
use. Based on that role some menu items will be visible or not
(example below is correct). I am sure this problem has been solved
before :-0 as this is a very normal usecase for context sensitive
navigation.
It seems that there is no way to force the page to re-render using getPage()?
Thanks for the feedback so far. I keep on coming up against this issue
and have not found a reasonable solution to the problem. The
javascript option seems to be best so far.
Pieter
On Tue, Nov 10, 2009 at 1:41 PM, Ernesto Reinaldo Barreiro
reier...@gmail.com wrote:
Even if you re-render your page components that are not dynamic will not
change their state: unless you create a new instance of the page, I guess.
By this I mean.
class MyPanel {
public MyPanel(id) {
PanelB panelB = new Panel(B);
panelB.setVisible(getSomeCondition());
}
}
Even if condition getSomeCondition() change, and you re-render MyPanel, or
the whole page, panelB will still be not visible. So, if you want something
to be dynamic you have to program it to be dynamic.
Best,
Ernesto
On Tue, Nov 10, 2009 at 1:20 PM, pieter claassen pieter.claas...@gmail.com
wrote:
Both of the suggestions I think requires me to modify the logic of the
controls (either to keep track of which ones need to be updated or by
placing the rendering logic in onBeforeRender()). I think this is a
lot of work for something relative straight forward and also any
changes to permission structures and I have to modify controls.
Is there no way that I can mark a page obtained via getPage() as
requiring re-rendering? I tried getPage().dirty() before the
setResponsePage() but that didn't do anything.
Thanks for the feedback though.
P
On Tue, Nov 10, 2009 at 1:10 PM, Pedro Santos pedros...@gmail.com wrote:
I tried setResponsePage(getPage()) but the problem is it does not
re-render controls on the page.
Where do you implement your control ( update logic )? Consider do it
overriding Component.onBeforeRender method
On Tue, Nov 10, 2009 at 10:03 AM, pieter claassen
pieter.claas...@gmail.com wrote:
Hi Pedro,
I tried setResponsePage(getPage()) but the problem is it does not
re-render controls on the page.
setResponsePage(getPage().getClass()) only works for stateless pages
and on most of my pages, I pass params via the constructor.
The javascript option will be a last resort, but it seems to be not
the most elegant solution.
Rgds,
On Tue, Nov 10, 2009 at 11:45 AM, Pedro Santos pedros...@gmail.com
wrote:
if(userSetWasChanged){
target.appendJavascript(window.location.reload());
or
setResponsePage(getPage());
or
setResponsePage(getPage().getClass());
}
On Tue, Nov 10, 2009 at 5:19 AM, pieter claassen
pieter.claas...@gmail.com
wrote:
I have a link on a panel that is included in many pages. When the
user
clicks on the link, I change something in the user settings that
will
affect what gets displayed on the page. However, for that to work, I
need to reload the page after the user clicked on the link as by
default the other components that now need to be checked for
conditional visibility don't re-render (why not?). setResponsePage()
requires me to pass into the panel a target page and this becomes
complex when you have a mix of statefull and stateless pages as
targets (and it just doesn't feel right).
I am sure there must be an easier way to just re-render a page?
Any tips?
Thanks,
pieter
smime.p7s
Description: S/MIME Cryptographic Signature
Re: Force page reload/re-render
The page will be re-rendered... Implement your menu item componentes
isVisible method to return true due your context
Enviado de meu iPhone
Em 10/11/2009, às 11:39, pieter claassen pieter.claas...@gmail.com
escreveu:
Hi Ernesto,
To recap, I have a control panel visible on each and every page and in
that control panel, you can select the appropriate role you want to
use. Based on that role some menu items will be visible or not
(example below is correct). I am sure this problem has been solved
before :-0 as this is a very normal usecase for context sensitive
navigation.
It seems that there is no way to force the page to re-render using
getPage()?
Thanks for the feedback so far. I keep on coming up against this issue
and have not found a reasonable solution to the problem. The
javascript option seems to be best so far.
Pieter
On Tue, Nov 10, 2009 at 1:41 PM, Ernesto Reinaldo Barreiro
reier...@gmail.com wrote:
Even if you re-render your page components that are not dynamic
will not
change their state: unless you create a new instance of the page, I
guess.
By this I mean.
class MyPanel {
public MyPanel(id) {
PanelB panelB = new Panel(B);
panelB.setVisible(getSomeCondition());
}
}
Even if condition getSomeCondition() change, and you re-render
MyPanel, or
the whole page, panelB will still be not visible. So, if you want
something
to be dynamic you have to program it to be dynamic.
Best,
Ernesto
On Tue, Nov 10, 2009 at 1:20 PM, pieter claassen pieter.claas...@gmail.com
wrote:
Both of the suggestions I think requires me to modify the logic of
the
controls (either to keep track of which ones need to be updated or
by
placing the rendering logic in onBeforeRender()). I think this is a
lot of work for something relative straight forward and also any
changes to permission structures and I have to modify controls.
Is there no way that I can mark a page obtained via getPage() as
requiring re-rendering? I tried getPage().dirty() before the
setResponsePage() but that didn't do anything.
Thanks for the feedback though.
P
On Tue, Nov 10, 2009 at 1:10 PM, Pedro Santos
pedros...@gmail.com wrote:
I tried setResponsePage(getPage()) but the problem is it does not
re-render controls on the page.
Where do you implement your control ( update logic )? Consider do
it
overriding Component.onBeforeRender method
On Tue, Nov 10, 2009 at 10:03 AM, pieter claassen
pieter.claas...@gmail.com wrote:
Hi Pedro,
I tried setResponsePage(getPage()) but the problem is it does not
re-render controls on the page.
setResponsePage(getPage().getClass()) only works for stateless
pages
and on most of my pages, I pass params via the constructor.
The javascript option will be a last resort, but it seems to be
not
the most elegant solution.
Rgds,
On Tue, Nov 10, 2009 at 11:45 AM, Pedro Santos pedros...@gmail.com
wrote:
if(userSetWasChanged){
target.appendJavascript(window.location.reload());
or
setResponsePage(getPage());
or
setResponsePage(getPage().getClass());
}
On Tue, Nov 10, 2009 at 5:19 AM, pieter claassen
pieter.claas...@gmail.com
wrote:
I have a link on a panel that is included in many pages. When
the
user
clicks on the link, I change something in the user settings that
will
affect what gets displayed on the page. However, for that to
work, I
need to reload the page after the user clicked on the link as by
default the other components that now need to be checked for
conditional visibility don't re-render (why not?).
setResponsePage()
requires me to pass into the panel a target page and this
becomes
complex when you have a mix of statefull and stateless pages as
targets (and it just doesn't feel right).
I am sure there must be an easier way to just re-render a page?
Any tips?
Thanks,
pieter
---
---
---
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
Pedro Henrique Oliveira dos Santos
--
Pieter Claassen
musmato.com
--
Pedro Henrique Oliveira dos Santos
--
Pieter Claassen
musmato.com
--
Pieter Claassen
musmato.com
-
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
Re: Force page reload/re-render
Hi Pieter,
Components that have .setVisible(false) will never be evaluated again
automatically. You need to call .setVisible(true) on all that apply.
One way would be control visibility in the base panel by overriding
onBeforeRender() to handle all the cases in one place. e.g.
class ControlPanel extends Panel {
protected void onBeforeRender () {
Role role = getModelObject();
caseOnePanel.setVisible(false);
caseTwoPanel.setVisible (false);
if (role instanceof CaseOne) {
caseOnePanel.setVisible (true);
}
else if (role instanceof CaseTwo) {
caseTwoPanel.setVisible (true);
}
}
}
Or you could override .isVisible() in your sub panels to control when
they are visible.
I like the on before render way myself because there is no performance
penalty if the visibility logic is complex (Component.isVisible() is
called alot during the rendering phase).
Regards,
Mike
To recap, I have a control panel visible on each and every page and in
that control panel, you can select the appropriate role you want to
use. Based on that role some menu items will be visible or not
(example below is correct). I am sure this problem has been solved
before :-0 as this is a very normal usecase for context sensitive
navigation.
It seems that there is no way to force the page to re-render using getPage()?
Thanks for the feedback so far. I keep on coming up against this issue
and have not found a reasonable solution to the problem. The
javascript option seems to be best so far.
Pieter
On Tue, Nov 10, 2009 at 1:41 PM, Ernesto Reinaldo Barreiro
reier...@gmail.com wrote:
Even if you re-render your page components that are not dynamic will not
change their state: unless you create a new instance of the page, I guess.
By this I mean.
class MyPanel {
public MyPanel(id) {
PanelB panelB = new Panel(B);
panelB.setVisible(getSomeCondition());
}
}
Even if condition getSomeCondition() change, and you re-render MyPanel, or
the whole page, panelB will still be not visible. So, if you want something
to be dynamic you have to program it to be dynamic.
Best,
Ernesto
On Tue, Nov 10, 2009 at 1:20 PM, pieter claassen pieter.claas...@gmail.com
wrote:
Both of the suggestions I think requires me to modify the logic of the
controls (either to keep track of which ones need to be updated or by
placing the rendering logic in onBeforeRender()). I think this is a
lot of work for something relative straight forward and also any
changes to permission structures and I have to modify controls.
Is there no way that I can mark a page obtained via getPage() as
requiring re-rendering? I tried getPage().dirty() before the
setResponsePage() but that didn't do anything.
Thanks for the feedback though.
P
On Tue, Nov 10, 2009 at 1:10 PM, Pedro Santos pedros...@gmail.com wrote:
I tried setResponsePage(getPage()) but the problem is it does not
re-render controls on the page.
Where do you implement your control ( update logic )? Consider do it
overriding Component.onBeforeRender method
On Tue, Nov 10, 2009 at 10:03 AM, pieter claassen
pieter.claas...@gmail.com wrote:
Hi Pedro,
I tried setResponsePage(getPage()) but the problem is it does not
re-render controls on the page.
setResponsePage(getPage().getClass()) only works for stateless pages
and on most of my pages, I pass params via the constructor.
The javascript option will be a last resort, but it seems to be not
the most elegant solution.
Rgds,
On Tue, Nov 10, 2009 at 11:45 AM, Pedro Santos pedros...@gmail.com
wrote:
if(userSetWasChanged){
target.appendJavascript(window.location.reload());
or
setResponsePage(getPage());
or
setResponsePage(getPage().getClass());
}
On Tue, Nov 10, 2009 at 5:19 AM, pieter claassen
pieter.claas...@gmail.com
wrote:
I have a link on a panel that is included in many pages. When the
user
clicks on the link, I change something in the user settings that
will
affect what gets displayed on the page. However, for that to work, I
need to reload the page after the user clicked on the link as by
default the other components that now need to be checked for
conditional visibility don't re-render (why not?). setResponsePage()
requires me to pass into the panel a target page and this becomes
complex when you have a mix of statefull and stateless pages as
targets (and it just doesn't feel right).
I am sure there must be an easier way to just re-render a page?
Any tips?
Thanks,
pieter
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
Pedro Henrique Oliveira dos Santos
--
Pieter Claassen
musmato.com
--
Pedro Henrique Oliveira dos Santos
--
Pieter Claassen
musmato.com
Re: Force page reload/re-render
Thanks for all the feedback. onBeforeRender() works like a charm.
Pieter
On Tue, Nov 10, 2009 at 2:51 PM, Michael O'Cleirigh
michael.ocleir...@rivulet.ca wrote:
Hi Pieter,
Components that have .setVisible(false) will never be evaluated again
automatically. You need to call .setVisible(true) on all that apply.
One way would be control visibility in the base panel by overriding
onBeforeRender() to handle all the cases in one place. e.g.
class ControlPanel extends Panel {
protected void onBeforeRender () {
Role role = getModelObject();
caseOnePanel.setVisible(false);
caseTwoPanel.setVisible (false);
if (role instanceof CaseOne) {
caseOnePanel.setVisible (true);
}
else if (role instanceof CaseTwo) {
caseTwoPanel.setVisible (true);
}
}
}
Or you could override .isVisible() in your sub panels to control when they
are visible.
I like the on before render way myself because there is no performance
penalty if the visibility logic is complex (Component.isVisible() is called
alot during the rendering phase).
Regards,
Mike
To recap, I have a control panel visible on each and every page and in
that control panel, you can select the appropriate role you want to
use. Based on that role some menu items will be visible or not
(example below is correct). I am sure this problem has been solved
before :-0 as this is a very normal usecase for context sensitive
navigation.
It seems that there is no way to force the page to re-render using
getPage()?
Thanks for the feedback so far. I keep on coming up against this issue
and have not found a reasonable solution to the problem. The
javascript option seems to be best so far.
Pieter
On Tue, Nov 10, 2009 at 1:41 PM, Ernesto Reinaldo Barreiro
reier...@gmail.com wrote:
Even if you re-render your page components that are not dynamic will
not
change their state: unless you create a new instance of the page, I
guess.
By this I mean.
class MyPanel {
public MyPanel(id) {
PanelB panelB = new Panel(B);
panelB.setVisible(getSomeCondition());
}
}
Even if condition getSomeCondition() change, and you re-render MyPanel,
or
the whole page, panelB will still be not visible. So, if you want
something
to be dynamic you have to program it to be dynamic.
Best,
Ernesto
On Tue, Nov 10, 2009 at 1:20 PM, pieter claassen
pieter.claas...@gmail.com
wrote:
Both of the suggestions I think requires me to modify the logic of the
controls (either to keep track of which ones need to be updated or by
placing the rendering logic in onBeforeRender()). I think this is a
lot of work for something relative straight forward and also any
changes to permission structures and I have to modify controls.
Is there no way that I can mark a page obtained via getPage() as
requiring re-rendering? I tried getPage().dirty() before the
setResponsePage() but that didn't do anything.
Thanks for the feedback though.
P
On Tue, Nov 10, 2009 at 1:10 PM, Pedro Santos pedros...@gmail.com
wrote:
I tried setResponsePage(getPage()) but the problem is it does not
re-render controls on the page.
Where do you implement your control ( update logic )? Consider do it
overriding Component.onBeforeRender method
On Tue, Nov 10, 2009 at 10:03 AM, pieter claassen
pieter.claas...@gmail.com wrote:
Hi Pedro,
I tried setResponsePage(getPage()) but the problem is it does not
re-render controls on the page.
setResponsePage(getPage().getClass()) only works for stateless pages
and on most of my pages, I pass params via the constructor.
The javascript option will be a last resort, but it seems to be not
the most elegant solution.
Rgds,
On Tue, Nov 10, 2009 at 11:45 AM, Pedro Santos pedros...@gmail.com
wrote:
if(userSetWasChanged){
target.appendJavascript(window.location.reload());
or
setResponsePage(getPage());
or
setResponsePage(getPage().getClass());
}
On Tue, Nov 10, 2009 at 5:19 AM, pieter claassen
pieter.claas...@gmail.com
wrote:
I have a link on a panel that is included in many pages. When the
user
clicks on the link, I change something in the user settings that
will
affect what gets displayed on the page. However, for that to work, I
need to reload the page after the user clicked on the link as by
default the other components that now need to be checked for
conditional visibility don't re-render (why not?). setResponsePage()
requires me to pass into the panel a target page and this becomes
complex when you have a mix of statefull and stateless pages as
targets (and it just doesn't feel right).
I am sure there must be an easier way to just re-render a page?
Any tips?
Thanks,
pieter
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
Re: force page reload
as it is kind of a workflow and i had all the pages already prepared
by passing imodels along into constructors, i didn't want to have a
bookmarkablepage (whatever you pick: panels/pages/variations, you need
this one to call the page executing the code). but this was the
simpler solution, pass an id to the non wicket server through http
post, get it back and initialize the a detachablemodel again with the
id and the dao.
so i changed a bit my code to fit this no-arg constructor page, which
is responsible of checking the http post params.
imo it is a good idea to use variations. a panel could have also been,
of course, but i wanted to avoid boilerplate for just a thank you. i
finally redirected to the next page. in any case, this is such a small
case that the approach is not so important here.
thanks all!
francisco
On Tue, Oct 7, 2008 at 1:36 AM, Jeremy Thomerson
[EMAIL PROTECTED] wrote:
I'd wholeheartedly agree with the panel solution. Either one would work,
but I think the panel is really good.
--
Jeremy Thomerson
http://www.wickettraining.com
On Mon, Oct 6, 2008 at 9:53 PM, John Krasnay [EMAIL PROTECTED] wrote:
On Mon, Oct 06, 2008 at 07:36:03PM -0200, francisco treacy wrote:
thanks for your help, serkan.
cool, this works. as a workaround nevertheless:
-i wouldn't want my app to check every single request the existence of
a parameter which i am going to use in only *one* page anyway
-what if i have this param passed to another page that doesn't expect
it? this could easily introduce new bugs
isn't there another easy way to force reloading / not caching a
page? why isn't setHeaders having any effect? should be
straightforward - what am i missing here?
thanks again anyone for some pointers!
francisco
It seems to me a bit strange to use markup variant for this. You could
have your callback page forward to the correct page like this:
public CallbackPage(PageParameters params) {
if (params.getString(DATA).equals(good)) {
setResponsePage(PaymentGoodPage.class);
} else {
setResponsePage(TryAgainPage.class);
}
}
Alternatively, you could instantiate an appropriate panel in your page:
public CallbackPage(PageParameters params) {
if (params.getString(DATA).equals(good)) {
add(new PaymentGoodPanel(responsePanel));
} else {
add(new TryAgainPanel(responsePanel));
}
}
jk
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: force page reload
Just throwing this out there:
http://wicketstuff.org/wicket13doc/org/apache/wicket/Page.html#setStatelessHint(boolean)
Perhaps that may work.
Ryan Gravener
http://twitter.com/ryangravener
On Tue, Oct 7, 2008 at 12:02 PM, francisco treacy
[EMAIL PROTECTED] wrote:
as it is kind of a workflow and i had all the pages already prepared
by passing imodels along into constructors, i didn't want to have a
bookmarkablepage (whatever you pick: panels/pages/variations, you need
this one to call the page executing the code). but this was the
simpler solution, pass an id to the non wicket server through http
post, get it back and initialize the a detachablemodel again with the
id and the dao.
so i changed a bit my code to fit this no-arg constructor page, which
is responsible of checking the http post params.
imo it is a good idea to use variations. a panel could have also been,
of course, but i wanted to avoid boilerplate for just a thank you. i
finally redirected to the next page. in any case, this is such a small
case that the approach is not so important here.
thanks all!
francisco
On Tue, Oct 7, 2008 at 1:36 AM, Jeremy Thomerson
[EMAIL PROTECTED] wrote:
I'd wholeheartedly agree with the panel solution. Either one would work,
but I think the panel is really good.
--
Jeremy Thomerson
http://www.wickettraining.com
On Mon, Oct 6, 2008 at 9:53 PM, John Krasnay [EMAIL PROTECTED] wrote:
On Mon, Oct 06, 2008 at 07:36:03PM -0200, francisco treacy wrote:
thanks for your help, serkan.
cool, this works. as a workaround nevertheless:
-i wouldn't want my app to check every single request the existence of
a parameter which i am going to use in only *one* page anyway
-what if i have this param passed to another page that doesn't expect
it? this could easily introduce new bugs
isn't there another easy way to force reloading / not caching a
page? why isn't setHeaders having any effect? should be
straightforward - what am i missing here?
thanks again anyone for some pointers!
francisco
It seems to me a bit strange to use markup variant for this. You could
have your callback page forward to the correct page like this:
public CallbackPage(PageParameters params) {
if (params.getString(DATA).equals(good)) {
setResponsePage(PaymentGoodPage.class);
} else {
setResponsePage(TryAgainPage.class);
}
}
Alternatively, you could instantiate an appropriate panel in your page:
public CallbackPage(PageParameters params) {
if (params.getString(DATA).equals(good)) {
add(new PaymentGoodPanel(responsePanel));
} else {
add(new TryAgainPanel(responsePanel));
}
}
jk
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: force page reload
yes... the page must be bookmarkable - so i need it anyway.
another question that pops out with your suggestion: when called, are
bookmarkable pages always instantiated? under any circumstance?
just to make sure that calling
http://localhost:8080/myapp/bookmarkable will always trigger the code.
sorry if this is obvious, i just never paid attention :)
francisco
On Tue, Oct 7, 2008 at 2:07 PM, Ryan Gravener [EMAIL PROTECTED] wrote:
Just throwing this out there:
http://wicketstuff.org/wicket13doc/org/apache/wicket/Page.html#setStatelessHint(boolean)
Perhaps that may work.
Ryan Gravener
http://twitter.com/ryangravener
On Tue, Oct 7, 2008 at 12:02 PM, francisco treacy
[EMAIL PROTECTED] wrote:
as it is kind of a workflow and i had all the pages already prepared
by passing imodels along into constructors, i didn't want to have a
bookmarkablepage (whatever you pick: panels/pages/variations, you need
this one to call the page executing the code). but this was the
simpler solution, pass an id to the non wicket server through http
post, get it back and initialize the a detachablemodel again with the
id and the dao.
so i changed a bit my code to fit this no-arg constructor page, which
is responsible of checking the http post params.
imo it is a good idea to use variations. a panel could have also been,
of course, but i wanted to avoid boilerplate for just a thank you. i
finally redirected to the next page. in any case, this is such a small
case that the approach is not so important here.
thanks all!
francisco
On Tue, Oct 7, 2008 at 1:36 AM, Jeremy Thomerson
[EMAIL PROTECTED] wrote:
I'd wholeheartedly agree with the panel solution. Either one would work,
but I think the panel is really good.
--
Jeremy Thomerson
http://www.wickettraining.com
On Mon, Oct 6, 2008 at 9:53 PM, John Krasnay [EMAIL PROTECTED] wrote:
On Mon, Oct 06, 2008 at 07:36:03PM -0200, francisco treacy wrote:
thanks for your help, serkan.
cool, this works. as a workaround nevertheless:
-i wouldn't want my app to check every single request the existence of
a parameter which i am going to use in only *one* page anyway
-what if i have this param passed to another page that doesn't expect
it? this could easily introduce new bugs
isn't there another easy way to force reloading / not caching a
page? why isn't setHeaders having any effect? should be
straightforward - what am i missing here?
thanks again anyone for some pointers!
francisco
It seems to me a bit strange to use markup variant for this. You could
have your callback page forward to the correct page like this:
public CallbackPage(PageParameters params) {
if (params.getString(DATA).equals(good)) {
setResponsePage(PaymentGoodPage.class);
} else {
setResponsePage(TryAgainPage.class);
}
}
Alternatively, you could instantiate an appropriate panel in your page:
public CallbackPage(PageParameters params) {
if (params.getString(DATA).equals(good)) {
add(new PaymentGoodPanel(responsePanel));
} else {
add(new TryAgainPanel(responsePanel));
}
}
jk
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: force page reload
If I understood you correctly, I've done something like this to show a
different page depending on a url parameter. You should override the
newRequestCycleProcessor() method of your application class, and return a
different request target from the resolve method. Here I return a
bookmarkablepagerequesttarget which creates a new home page if a certain
parameter exists in the request:
@Override
protected IRequestCycleProcessor newRequestCycleProcessor() {
return new WebRequestCycleProcessor() {
@Override
public IRequestTarget resolve(RequestCycle cycle, RequestParameters
params) {
if (null !=
params.getParameters().get(ContentSearchPage.PARAM_SEARCH_KEY)) {
return new
BookmarkablePageRequestTarget(ContentSearchPage.class);
}
return super.resolve(cycle, params);
}
};
}
-Original Message-
From: francisco treacy [mailto:[EMAIL PROTECTED]
Sent: Mon 10/6/2008 10:07 PM
To: users@wicket.apache.org
Subject: force page reload
hi,
i'm integrating a wicket application with an online payment system
provided by a bank.
i have a wicket stateful page (ie shows visa / mastercard icons) which
links to the bank app's payment page. depending on the transaction,
the bank sends us back a result code in an encrypted http url
parameter, appended to the url of our wicket page.
String encrypted =
getWebRequestCycle().getWebRequest().getHttpServletRequest().getParameter(DATA);
according to the bank's response, i decide whether to show a please
pay or a thank you page with wicket variations.
the only problem i am having here is: the wicket page is cached, so no
matter what the result is, it will show the last seen version in the
pagemap - that is, it won't re-execute the page's java code.
i tried overriding headers
protected void setHeaders(WebResponse response) {
response.setHeader(Pragma, no-cache);
response.setDateHeader(Expires,0);
response.setHeader(Cache-Control, no-cache, max-age=0,
must-revalidate, no-store);
}
but none of these http headers are seen in the html output whatsoever.
i also tried implementing IMarkupCacheKeyProvider and returning null.
with no success so far.
what should i do to execute the page's code, no matter when it is called?
thanks,
francisco
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: force page reload
On Mon, Oct 06, 2008 at 07:36:03PM -0200, francisco treacy wrote:
thanks for your help, serkan.
cool, this works. as a workaround nevertheless:
-i wouldn't want my app to check every single request the existence of
a parameter which i am going to use in only *one* page anyway
-what if i have this param passed to another page that doesn't expect
it? this could easily introduce new bugs
isn't there another easy way to force reloading / not caching a
page? why isn't setHeaders having any effect? should be
straightforward - what am i missing here?
thanks again anyone for some pointers!
francisco
It seems to me a bit strange to use markup variant for this. You could
have your callback page forward to the correct page like this:
public CallbackPage(PageParameters params) {
if (params.getString(DATA).equals(good)) {
setResponsePage(PaymentGoodPage.class);
} else {
setResponsePage(TryAgainPage.class);
}
}
Alternatively, you could instantiate an appropriate panel in your page:
public CallbackPage(PageParameters params) {
if (params.getString(DATA).equals(good)) {
add(new PaymentGoodPanel(responsePanel));
} else {
add(new TryAgainPanel(responsePanel));
}
}
jk
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: force page reload
I'd wholeheartedly agree with the panel solution. Either one would work,
but I think the panel is really good.
--
Jeremy Thomerson
http://www.wickettraining.com
On Mon, Oct 6, 2008 at 9:53 PM, John Krasnay [EMAIL PROTECTED] wrote:
On Mon, Oct 06, 2008 at 07:36:03PM -0200, francisco treacy wrote:
thanks for your help, serkan.
cool, this works. as a workaround nevertheless:
-i wouldn't want my app to check every single request the existence of
a parameter which i am going to use in only *one* page anyway
-what if i have this param passed to another page that doesn't expect
it? this could easily introduce new bugs
isn't there another easy way to force reloading / not caching a
page? why isn't setHeaders having any effect? should be
straightforward - what am i missing here?
thanks again anyone for some pointers!
francisco
It seems to me a bit strange to use markup variant for this. You could
have your callback page forward to the correct page like this:
public CallbackPage(PageParameters params) {
if (params.getString(DATA).equals(good)) {
setResponsePage(PaymentGoodPage.class);
} else {
setResponsePage(TryAgainPage.class);
}
}
Alternatively, you could instantiate an appropriate panel in your page:
public CallbackPage(PageParameters params) {
if (params.getString(DATA).equals(good)) {
add(new PaymentGoodPanel(responsePanel));
} else {
add(new TryAgainPanel(responsePanel));
}
}
jk
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
