See http://markmail.org/message/ofyvgybcjp5cvf75
You talk about the same idea. Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Tue, Sep 16, 2014 at 12:10 PM, Bernard <bht...@gmail.com> wrote: > Martin, > > First I appreciate very much your hard work in the mailing list and > Jira space. > > Re 1. I accept this, but before developing ideas, I would want to > reach some consensus that there is a chance of having some change > implemented in wicket core. > > Re 2. The use case needs page state because it uses panel replacement > where the last state must be the only available state. The previous > state must be destroyed and not be available to the user even after > reload. That is the whole point, the solution that solves the back > button problem in this use case. I see from your comment that I did > perhaps not explain the use case. But my dilemma is when I write too > much about the use case, then I would lose the compactness and clarity > of the issue. Of course there are potentially other solutions not > involving page state but alternatively session state but these would > depart from wicket patterns. I would feel more like programming Spring > MVC or similar technologies lacking the power of Wicket. > > More below inline ... > > On Mon, 15 Sep 2014 10:24:41 +0300, you wrote: > > >Hi, > > > >I think it should not be re-opened! > > > >1. JIRA is not support forum! > >If you have questions then you should ask here (at users@ mailing list). > >If you have ideas then you should discuss them at dev@ mailing list. > > > >2. If you want to not have the ?pageId in the url then you should stick to > >stateless components and behaviors. > >This is by design! > >Stateful pages cannot work without the pageId parameter! > > What if Wicket switches processing in case of setVersion(false)? What > would stop us from letting Wicket use a singleton page "version" if > setVersion(false), making the version parameter entirely obsolete? > This appears to be very logical to me. As I wrote in the Jira ticket, > setVersioned(false) should just do what the word means. Currently that > is not the case because we are saying Wicket needs the version number. > > >Solutions like NoVersionRequestMapper are pure hacks. Use them at your own > >responsibility! Wicket developers are not responsible for them! > > > > We want to change that. Honestly, this is the whole point. I am sick > of these hacks that get broken because of what they are! > > > >3. Wicket provides some default implementations for IRequestMapper > >interface. > >But it also allows you to provide your own when you believe the default > >ones are not optimal for you. > Same as above if I understand this right. I really don't feel strong > enough about changing low level internals too much - risk of getting > broken. > > >3.1. Wicket does its best to be backward compatible with previous > versions. > >Before every release we test the suggested new release with as much > >applications as we have. If we find a regression we cancel the release and > >cut a new one. You are very welcome to join us with testing your > >application, with your custom implementations of Wicket interfaces, and > >report regressions ! > > Thanks for that. I am afraid of getting into some hacking mode where > my custom implementation gets broken and I would just waste your time. > > > > > > >I'll copy my response to the ticket for cross reference. > > > >Martin Grigorov > >Wicket Training and Consulting > >https://twitter.com/mtgrigorov > > > >On Sun, Sep 14, 2014 at 10:55 AM, Bernard <bht...@gmail.com> wrote: > > > >> Hi, > >> > >> I created a Jira issue > >> > >> https://issues.apache.org/jira/browse/WICKET-5693 > >> setVersioned(false) should force single Page Version > >> > >> Initially information was not sufficient or clear enough so the issue > >> was closed. > >> > >> Meanwhile I have added the requested information. > >> > >> Could this issue please be re-opened. > >> > >> Many thanks. > >> > >> Bernard > >> > >> --- > >> This email is free from viruses and malware because avast! Antivirus > >> protection is active. > >> http://www.avast.com > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > >> For additional commands, e-mail: users-h...@wicket.apache.org > >> > >> > > > --- > This email is free from viruses and malware because avast! Antivirus > protection is active. > http://www.avast.com > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
