Re: chrome + wicket ajax + back button = problem?

[Ryan Crumley]

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,  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.

Re: chrome + wicket ajax + back button = problem?

[Ryan Crumley]

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  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  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.html>Ryan
> >
> > On Fri, Sep 24, 2010 at 1:48 AM, Peter Karich  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?

[Ryan Crumley]

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

Ryan

On Fri, Sep 24, 2010 at 1:48 AM, Peter Karich  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
>
>

chrome + wicket ajax + back button = problem?

[Ryan Crumley]

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: wicketstuff-merged-resources 3.1 parent class scanning?

[Ryan Crumley]

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  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
>>   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  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
>
>

Re: wicketstuff-merged-resources 3.1 parent class scanning?

[Ryan Crumley]

rcrumley

On Fri, May 21, 2010 at 10:04 AM, Jeremy Thomerson
 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  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
>>  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  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?

[Ryan Crumley]

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
 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  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

wicketstuff-merged-resources 3.1 parent class scanning?

[Ryan Crumley]

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: Static link for stateful page (Wicket 1.3)

[Ryan Crumley]

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  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

Static link for stateful page (Wicket 1.3)

[Ryan Crumley]

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

[Ryan Crumley]

Matt,

Add this to your WebApplication.init() method:

getResourceSettings().setResourcePollFrequency(null);

Ryan

On Wed, Apr 8, 2009 at 9:33 PM, Matthew Welch  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