Static link for stateful page (Wicket 1.3)
Hi all,
I have an unusual requirement for a stateful page that can be accessed
via a static url. To state it another way I would like the same url to
always shows the latest state of a page for that session. For example:
Operations:
1. Initial Render. url = http://ABC/XYZ
2. User changes the page state using links ajax operations
3. User returns to url = http://ABC/XYZ and the operations from step
#2 are present from the same url visited in step #1.
I tried modifying my page so that it was not versioned and hardcoding
the numeric id to 0. This works for the first render but the changes
made to the page on the first render are not reflected when that same
url is refreshed. Here is the snippet of code I am using to generate
the static url:
PageMap pageMap = PageMap.forName(myMapName);
Page page = pageMap.get(0, -1);
if(page == null) {
page = new MyPage(pageMap);
}
return getRequestCycle().urlFor(page).toString();
Seems like there is an elegant way to do this, any pointers? I am
using Wicket 1.3.
Thanks in advance,
Ryan
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Static link for stateful page (Wicket 1.3)
After some thought I have a better description of what I am trying to do:
- I would like to have a stateless page that is always accessed via a
bookmarkable link.
- This page has an iframe whose content is backed by a stateful page
that is altered via ajax links.
- When the parent page is refreshed via the bookmarkable link I would
like the state in the iframe to persist (eg the iframe content is
rendered exactly as it was left before the refresh).
The question boils down to how to generate a link to the stateful page
that always points to the latest version of the page. The link can
change from render to render as long as the link can be generated
statelessly (because the containing page is stateless).
In case anyone is curious the real use case is a dynamically generated
javascript file that writes the iframe and other features into any
host page (similar to getsatisfaction.com or nabble.com).
Any hints on how to go about this are appreciated.
Ryan
On Mon, Nov 30, 2009 at 6:06 PM, Ryan Crumley crum...@gmail.com wrote:
Hi all,
I have an unusual requirement for a stateful page that can be accessed
via a static url. To state it another way I would like the same url to
always shows the latest state of a page for that session. For example:
Operations:
1. Initial Render. url = http://ABC/XYZ
2. User changes the page state using links ajax operations
3. User returns to url = http://ABC/XYZ and the operations from step
#2 are present from the same url visited in step #1.
I tried modifying my page so that it was not versioned and hardcoding
the numeric id to 0. This works for the first render but the changes
made to the page on the first render are not reflected when that same
url is refreshed. Here is the snippet of code I am using to generate
the static url:
PageMap pageMap = PageMap.forName(myMapName);
Page page = pageMap.get(0, -1);
if(page == null) {
page = new MyPage(pageMap);
}
return getRequestCycle().urlFor(page).toString();
Seems like there is an elegant way to do this, any pointers? I am
using Wicket 1.3.
Thanks in advance,
Ryan
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Turning off ModificationWatcher
Matt, Add this to your WebApplication.init() method: getResourceSettings().setResourcePollFrequency(null); Ryan On Wed, Apr 8, 2009 at 9:33 PM, Matthew Welch matt...@welchkin.net wrote: I'm experimenting with Wicket inside Google's new Java support for its App Engine. My simple apps run fine if the configuration is set to DEPLOYMENT, however in development mode, I get an exception related to ModificationWatcher. Looking at the exception I think this ModificationWatcher is being used as part of a new thread which is a no-no inside the App Engine sandbox. Is there way way to just disbable this modification watcher without putting the entire app in deployment mode? There are a number of items I like about development mode but this one glitch is preventing me from using it. Matt - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
wicketstuff-merged-resources 3.1 parent class scanning?
All,
[If there is a wicketstuff specific mailing list please let me know
and I will be happy to post there (wicketstuff.org is down so its
difficult to find information).]
I am using wicketstuff-merged-resources (3.1-SNAPSHOT) with
wicketstuff-annotation (1.1) and I have found a potential issue with
annotation detection. My page hierarchy looks something like this:
public abstract class BasePage extends WebPage { ... }
public class HomePage extends BasePage { ... }
I would like to add @JsContribution to BasePage however the resources
are only included if the concrete page (in this example: 'HomePage')
also has resource annotations. Removing @JsContribution from HomePage
results in all resources from BasePage also disappearing. Is this a
known bug? Am I using the framework incorrectly?
Thanks in advance for any guidance.
Ryan
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: wicketstuff-merged-resources 3.1 parent class scanning?
Thanks Jeremy. I applied the patches and there are some more errors
down the line. I am looking into resolving them and will submit a
patch once I get to that point. Hopefully this weekend.
Ryan
On Mon, May 17, 2010 at 11:49 PM, Jeremy Thomerson
jer...@wickettraining.com wrote:
I'm not a maintainer on those projects so I defer on applying the following
patches. However, I think that it is a bug. If it is a bug, it will also
require a change in the annotations project in WicketStuff. I have created
a patch for each. Could you test it and see if it works? If so, I'll go
ahead and commit it (unless one of the maintainers objects here first).
Patch for annotations: http://pastebin.com/nxQuLfqf
Patch for merged-resources: http://pastebin.com/Cbpjtvqp
File attachments to the list will be stripped.
--
Jeremy Thomerson
http://www.wickettraining.com
On Mon, May 17, 2010 at 9:43 PM, Ryan Crumley crum...@gmail.com wrote:
All,
[If there is a wicketstuff specific mailing list please let me know
and I will be happy to post there (wicketstuff.org is down so its
difficult to find information).]
I am using wicketstuff-merged-resources (3.1-SNAPSHOT) with
wicketstuff-annotation (1.1) and I have found a potential issue with
annotation detection. My page hierarchy looks something like this:
public abstract class BasePage extends WebPage { ... }
public class HomePage extends BasePage { ... }
I would like to add @JsContribution to BasePage however the resources
are only included if the concrete page (in this example: 'HomePage')
also has resource annotations. Removing @JsContribution from HomePage
results in all resources from BasePage also disappearing. Is this a
known bug? Am I using the framework incorrectly?
Thanks in advance for any guidance.
Ryan
-
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: wicketstuff-merged-resources 3.1 parent class scanning?
rcrumley
On Fri, May 21, 2010 at 10:04 AM, Jeremy Thomerson
jer...@wickettraining.com wrote:
What's your sf.net ID? I can add you as committer and you can just commit
the patches.
--
Jeremy Thomerson
http://www.wickettraining.com
On Fri, May 21, 2010 at 9:35 AM, Ryan Crumley crum...@gmail.com wrote:
Thanks Jeremy. I applied the patches and there are some more errors
down the line. I am looking into resolving them and will submit a
patch once I get to that point. Hopefully this weekend.
Ryan
On Mon, May 17, 2010 at 11:49 PM, Jeremy Thomerson
jer...@wickettraining.com wrote:
I'm not a maintainer on those projects so I defer on applying the
following
patches. However, I think that it is a bug. If it is a bug, it will
also
require a change in the annotations project in WicketStuff. I have
created
a patch for each. Could you test it and see if it works? If so, I'll
go
ahead and commit it (unless one of the maintainers objects here first).
Patch for annotations: http://pastebin.com/nxQuLfqf
Patch for merged-resources: http://pastebin.com/Cbpjtvqp
File attachments to the list will be stripped.
--
Jeremy Thomerson
http://www.wickettraining.com
On Mon, May 17, 2010 at 9:43 PM, Ryan Crumley crum...@gmail.com wrote:
All,
[If there is a wicketstuff specific mailing list please let me know
and I will be happy to post there (wicketstuff.org is down so its
difficult to find information).]
I am using wicketstuff-merged-resources (3.1-SNAPSHOT) with
wicketstuff-annotation (1.1) and I have found a potential issue with
annotation detection. My page hierarchy looks something like this:
public abstract class BasePage extends WebPage { ... }
public class HomePage extends BasePage { ... }
I would like to add @JsContribution to BasePage however the resources
are only included if the concrete page (in this example: 'HomePage')
also has resource annotations. Removing @JsContribution from HomePage
results in all resources from BasePage also disappearing. Is this a
known bug? Am I using the framework incorrectly?
Thanks in advance for any guidance.
Ryan
-
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: wicketstuff-merged-resources 3.1 parent class scanning?
Stefan,
I apologize for checking in changes without your approval. I was excited
about using your project but without scanning super classes it was not
useful to me. I was eager to get it working. =)
These are all good points... I will follow up with you off-list once I have
a few minutes to put together a response and a test case.
Cheers,
Ryan
On Thu, Jun 24, 2010 at 5:52 AM, Stefan Fussenegger s...@molindo.at wrote:
Hi Ryan,
I'm the maintainer of wicketstuff-merged-resources. Sorry, I don't watch
the mailing list as closely as I probably should.
I've just reverted your changes as the project wasn't able to build. The
required org.wicketstuff:annotations:1.4.7-SNAPSHOT isn't available from a
public repository - at least none I know of. Additionally, there are some
other problems:
- I'm not happy with a change in dependencies. Could you explain why you
went for org.wicketstuff:annotations rather than
org.wicketstuff:wicketstuff-annotations? Is this the official replacement?
- Your implementation of ResourceMount.enableAnnotations(...) is broken. It
won't work as soon as you need a second ContributionScanner for a different
package.
- Try to keep binary compatibility with previous versions. Don't add new
parameters to methods. Try to keep the old one, add a new one with an
additional parameter and call it from the old one with a default that
maintains the old behavior.
Next time, please use JIRA at http://wicketstuff.org/jira/browse/WMR (when
will it be back again? or will it be back at all?) to create a ticket (and
submit a patch) in order to get my feedback earlier (I'm watching the feeds
there and should be able to react pretty quickly).
Regarding your issue, wouldn't it be enough it @*Contribution would be
@Inherited and superclasses of matching classes would be checked as well for
potentially overridden annotations? Could you provide a test case for your
issues so we can figure out if there isn't a less obtrusive way to fix it?
Cheers, Stefan
On 05/21/2010 04:35 PM, Ryan Crumley wrote:
Thanks Jeremy. I applied the patches and there are some more errors
down the line. I am looking into resolving them and will submit a
patch once I get to that point. Hopefully this weekend.
Ryan
On Mon, May 17, 2010 at 11:49 PM, Jeremy Thomerson
jer...@wickettraining.com wrote:
I'm not a maintainer on those projects so I defer on applying the
following
patches. However, I think that it is a bug. If it is a bug, it will
also
require a change in the annotations project in WicketStuff. I have
created
a patch for each. Could you test it and see if it works? If so, I'll go
ahead and commit it (unless one of the maintainers objects here first).
Patch for annotations: http://pastebin.com/nxQuLfqf
Patch for merged-resources: http://pastebin.com/Cbpjtvqp
File attachments to the list will be stripped.
--
Jeremy Thomerson
http://www.wickettraining.com
On Mon, May 17, 2010 at 9:43 PM, Ryan Crumleycrum...@gmail.com wrote:
All,
[If there is a wicketstuff specific mailing list please let me know
and I will be happy to post there (wicketstuff.org is down so its
difficult to find information).]
I am using wicketstuff-merged-resources (3.1-SNAPSHOT) with
wicketstuff-annotation (1.1) and I have found a potential issue with
annotation detection. My page hierarchy looks something like this:
public abstract class BasePage extends WebPage { ... }
public class HomePage extends BasePage { ... }
I would like to add @JsContribution to BasePage however the resources
are only included if the concrete page (in this example: 'HomePage')
also has resource annotations. Removing @JsContribution from HomePage
results in all resources from BasePage also disappearing. Is this a
known bug? Am I using the framework incorrectly?
Thanks in advance for any guidance.
Ryan
-
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
chrome + wicket ajax + back button = problem?
All, I ran into strange behavior involving wicket ajax updates + chrome + back button. I am pretty sure the issue is not caused by wicket but I am hoping the problem might sound familiar to someone and they can point me in the right direction. The scenario goes like this: - An ajax request is made that updates the DOM. - The user navigates to another page by clicking on a link. - The user uses the browser back button to go back to the original page. After clicking back Google Chrome shows the page as it was originally rendered (before the DOM update). All other browsers show the page as it was when the user left the page (with the DOM update). Besides the possibility of showing stale data the other problem is that the page state has been altered by the ajax request and links that were originally rendered may no longer be valid. I found a few links where people are having similar issues: http://www.maintaino.com/nuts-and-bolts/2010/04/08/teaching-chrome-not-to-cache-your-rails-pages/ Possibly related to using jQuery and/or window.onUnload() and bfcache: http://stackoverflow.com/questions/158319/cross-browser-onload-event-and-the-back-button https://developer.mozilla.org/En/Using_Firefox_1.5_caching In addition to using Wicket 1.4.12 I am also using jQuery 1.4.2 and google analytics on these pages. I don't think any unload handlers have been added however my only check was looking at all the attributes on the window object via the inspector. Has anyone else seen similar behavior? Even better, anyone else have a solution? You may be seeing errors like this one in your logs: org.apache.wicket.protocol.http.request.InvalidUrlException: org.apache.wicket.WicketRuntimeException: component wid1:wid2:1:wid3 not found on page com.foo.xxx Thanks! Ryan
Re: chrome + wicket ajax + back button = problem?
What is interesting is this is not a wicket specific issue however it is more serious when using wicket than other frameworks due to the expired links causing errors when they reappear. I created a very simple version of the problem. Chrome and IE8 exhibits the problem but Firefox and Safari do not: http://www.cupofcrumley.com/chrome-test/Page1.html http://www.cupofcrumley.com/chrome-test/Page1.htmlRyan On Fri, Sep 24, 2010 at 1:48 AM, Peter Karich peat...@yahoo.de wrote: I had the same problem ... Take a look at http://www.richardnichols.net/2010/03/apache-wicket-force-page-reload-to-fix-ajax-back/ isn't there a better fix? E.g. it seems to me that this 'hack' avoids client-side js caching (or is this a wrong observation)? Regards, Peter. -- http://jetwick.com twitter search prototype - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: chrome + wicket ajax + back button = problem?
Just to clarify: The page in the example link I sent is stateless (it's static html). The other point is that Chrome and IE do not fetch the original page on back button click. They are serving the original html straight from the cache (without the DOM modifications). It sounds like the only fix is to update the page headers so that no browser will ever cache the page. That seems like an overkill but so far I haven't found any other solution that works across browsers. This seems like a very common scenario... is it also very common to set all the no-cache headers? Ryan On Sun, Oct 3, 2010 at 5:56 PM, Zilvinas Vilutis cika...@gmail.com wrote: Yes, it is not repeatable on FF because FF does page caching which IE does not for Back history. Your page must be stateless on the server side. Žilvinas Vilutis Mobile: (+370) 652 38353 E-mail: cika...@gmail.com On Sun, Oct 3, 2010 at 3:47 PM, Ryan Crumley crum...@gmail.com wrote: What is interesting is this is not a wicket specific issue however it is more serious when using wicket than other frameworks due to the expired links causing errors when they reappear. I created a very simple version of the problem. Chrome and IE8 exhibits the problem but Firefox and Safari do not: http://www.cupofcrumley.com/chrome-test/Page1.html http://www.cupofcrumley.com/chrome-test/Page1.htmlRyan On Fri, Sep 24, 2010 at 1:48 AM, Peter Karich peat...@yahoo.de wrote: I had the same problem ... Take a look at http://www.richardnichols.net/2010/03/apache-wicket-force-page-reload-to-fix-ajax-back/ isn't there a better fix? E.g. it seems to me that this 'hack' avoids client-side js caching (or is this a wrong observation)? Regards, Peter. -- http://jetwick.com twitter search prototype - 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: chrome + wicket ajax + back button = problem?
I have (I am using MixedParamHybridUrlCodingStrategy) however in this case the browser is not contacting the server on back button click so the UrlCodingStrategy does not come into play. Ryan On Wed, Oct 6, 2010 at 4:13 PM, mzem...@osc.state.ny.us wrote: I've had similar issues, have you tried HybridUrlCodingStrategy? Notice: This communication, including any attachments, is intended solely for the use of the individual or entity to which it is addressed. This communication may contain information that is protected from disclosure under State and/or Federal law. Please notify the sender immediately if you have received this communication in error and delete this email from your system. If you are not the intended recipient, you are requested not to disclose, copy, distribute or take any action in reliance on the contents of this information.
