You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Bernard <bh...@gmail.com> on 2014/09/14 09:55:56 UTC
Request for re-opening a Jira issue
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Request for re-opening a Jira issue
Posted by Martin Grigorov <mg...@apache.org>.
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 <bh...@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 <bh...@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-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Request for re-opening a Jira issue
Posted by Bernard <bh...@gmail.com>.
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 <bh...@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-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Request for re-opening a Jira issue
Posted by Martin Grigorov <mg...@apache.org>.
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!
Solutions like NoVersionRequestMapper are pure hacks. Use them at your own
responsibility! Wicket developers are not responsible for them!
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.
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 !
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 <bh...@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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>