problem with google Calendar while upgrading from wicket 1.5 to 6.9
I am using Google Calendar Service in my wicket application, which I bring now up to wicket 6.9. First I had to upgrade to com.google.gdata core 1.47.1 because of other guava dependencies. When I include the Statement; CalendarService myService = new CalendarService(exampleCo-exampleApp-1); I get the error: java.io.NotSerializableException: com.google.gdata.client.calendar.CalendarService Best regards H.Braun
Stateful / versioned / bookmarkable
Afaik stateful pages are always versioned. I wonder about these two questions: 1. In this case links to versioned pages are not bookmarkable (since they contain the verion identifier). Correct? This would meen that stateful pages cannot have bookmarkable links. But this contradicts some statements in the wicket documenbtation (e.g. https://cwiki.apache.org/confluence/display/WICKET/Pages). 2. I believe having stateful pages without versioninig are a valid use case (i.e. storing just one page instance per page, e.g. for caching pre calculated values or remembering some GUI settings, the back button leads always to the same stored instance). Are there good reasons to avoid such a scenario? Or are there good practices to achive it? Thanks, Frank -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Stateful-versioned-bookmarkable-tp4661990.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Stateful / versioned / bookmarkable
Hi, 1) Stateful pages don't need to be versioned: setVersioned(false). But they get a version id in the URL nevertheless, meaning the implementation is not as good as it could be. A stateful page can be bookmarkable. As said above, you get 2 URLs for it, not unique. 2) I agree this has valid use cases, e.g. where the user works with a page that changes state, e.g. via panel replacement, and the user should NOT be able to go back to any of the previous states. Otherwise one cannot implement a reliable state machine if the user can undermine it with back button support. Wicket should support this use case, but AFAIK it does not. We have been able to code various workarounds but there is a problem with these workarounds: They are not stable - Wicket has broken these with subsequent releases - and I have given up playing this cat and mouse game. So until a non-versioned URL coding strategy becomes part of the Wicket core, this will remainin a frustrating up-hill battle. Please note that there will likely not be a 100% perfect solution to this because of the servlet API. On the first page visit, the container adds a jsessionid parameter to the URL until cookie support is established. In that case, there will still be 2 URLs for the same non-versioned page, even without a versioning parameter in the URL. But that is only a minor issue if you can put another page in front of your non-versioned page. Summing it up, I would suggest that you create a Jira issue for Wicket non-versioned URL support for our use cases. A page has to be mountable with such a policy so that as you say, only the latest version is available, and that must be reflected in a stable URL where ony one unique value exists. It can be done, it has been done before, it is just a matter of good will and policy. The Post-Redirect-Get pattern supports this, and I know that other frameworks support this, too. Regards, Bernard On Sun, 27 Oct 2013 05:26:07 -0700 (PDT), you wrote: Afaik stateful pages are always versioned. I wonder about these two questions: 1. In this case links to versioned pages are not bookmarkable (since they contain the verion identifier). Correct? This would meen that stateful pages cannot have bookmarkable links. But this contradicts some statements in the wicket documenbtation (e.g. https://cwiki.apache.org/confluence/display/WICKET/Pages). 2. I believe having stateful pages without versioninig are a valid use case (i.e. storing just one page instance per page, e.g. for caching pre calculated values or remembering some GUI settings, the back button leads always to the same stored instance). Are there good reasons to avoid such a scenario? Or are there good practices to achive it? Thanks, Frank - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
NullAjaxRequestTarget
Wicketeers,
I have a minor issue, rather than any bug, and thought I'd throw it out there.
We tend to use a lot of AjaxFallbackLinks, for obvious reasons. The biggest
problem of AjaxFallbackLink is the line of code;
@Override
public final void onClick()
{
onClick(null);
}
Because null can potentially be passed to the onClick(AjaxRequestTarget target)
method, in every case we has to use code as;
If( target != null ) {
target.add(...);
}
Ad infinitum. When we don't we are potentially letting in bugs each time and 99
times out of 100 developers will forget, which means we have bugs that usually
only trigger when a user does a open in new window click or if they've
happened to turn of JavaScript - so while they are difficult for the user to
trigger they are still there.
Is there any chance of un-finalising onClick(), or better yet, having it
provide a Null Object (http://en.wikipedia.org/wiki/Null_Object_pattern)
instead of null, in order to reduce developer effort and reduce hard to find
bugs?
Obviously this is a minor, minor thing...
Cheers,
Col.
EMAIL DISCLAIMER This email message and its attachments are confidential and
may also contain copyright or privileged material. If you are not the intended
recipient, you may not forward the email or disclose or use the information
contained in it. If you have received this email message in error, please
advise the sender immediately by replying to this email and delete the message
and any associated attachments. Any views, opinions, conclusions, advice or
statements expressed in this email message are those of the individual sender
and should not be relied upon as the considered view, opinion, conclusions,
advice or statement of this company except where the sender expressly, and with
authority, states them to be the considered view, opinion, conclusions, advice
or statement of this company. Every care is taken but we recommend that you
scan any attachments for viruses.
