i am not saying we shouldntve fixed it to return an array always, what i am
saying is that it is inconsistent because when we put things into that map
we dont wrap them in an array, and we should, no?
I don't know whether we should. Those are parameters we ourselves
added, so however we'd add
see my comment on: https://issues.apache.org/jira/browse/WICKET-400
i think we should change the RequestParamters.getParamters()
don't return a map there but return a ValueMap so that we shield it that it
could be request parameters directly (with things from use added)
then they can call
http://localhost:8080/NT/front/?wicket:bookmarkablePage=:mypackage.EntryPointPageDATA=MOGToh0GbqF%7Et3MZzj8cLc9ruPY-ArazzQcA9%7EFO1e6ivBTv-2tSFD8gd4L0MAtXL2xnud0JujjIhjBUVpDHcE82KiBJ7PK-1T3BamoQyx9QnzEsz7PD1li0Wq%7EvOU87
As you see there, the DATA parameter sent has been mysteriously
Hi, Johan,
Switching all
... = (String)pageParam.get(...);
to
... = pageParam.getString(...);
made it work.
Why didnt you mention switching to getString before?
Nevertheless, should we understand that get does not behaves as
1.2.5, where String was returned, and not String[1] as 1.2.6.
i didn't exactly know at what place you get what from where.
for example if you did it through: request.getRequestParameters
().getParameters()
then we just return a map which i think we should fix.. (we should return a
ValueMap there)
so that you also can do getString()
johan
On 5/15/07,
for example if you did it through:
request.getRequestParameters().getParameters()
then we just return a map which i think we should fix.. (we should return a
ValueMap there)
so that you also can do getString()
Yes, that's the point. Sometimes I was doing this in 1.2.5:
public class the-page
Hi, Al,
Construct your page with:
public MyPage(PageParams params) {
Yes, I already do this in all my pages...
You can then go:
String[] colors = params.getStringArray(color);
(Which obviously returns the whole array.)
Or:
String color = params.getString(color);
(Which just returns the
* manuel barzi:
Unfortunatelly, I have to confirm you this is actually not true
in 1.2.6 (I guess the link provided by Jean-Baptiste Quenot is
explaining it all).
In my case I just transfer independent key-values (never
repeated), and when recovering them at the
Hi, Jean-Baptiste,
See:
ClassCastException in WebRequestCodingStrategy
https://issues.apache.org/jira/browse/WICKET-524
This link is about Apache Wicket Project, but not the Wicket
Standalone Project, which is the currently I am using in my
development. Or is that link valid for both cases?
* manuel barzi:
Hi, Jean-Baptiste,
See:
ClassCastException in WebRequestCodingStrategy
https://issues.apache.org/jira/browse/WICKET-524
This link is about Apache Wicket Project, but not the Wicket
Standalone Project, which is the currently I am using in my
development. Or is that
You may want to try the patch attached to the Jira issue. But
note that this is a workaround, not really a solution to the
problem as I don't know where those String arrays come from.
So, should I better switch back to wicket-1.2.5???
Please, confirm to me what's the best decision
the String arrays come from the change eelco did in the ServletWebRequest:
public Map getParameterMap()
{
// Lazy-init parameter map. Only make one copy. It's more efficient,
and
// we can add stuff to it (which the BookmarkablePage stuff does).
if (parameterMap ==
but you see how this leads to inconsistencies right? all of a sudden some
things are arrays (params coming from request) while others are not (params
we put in). so its messy.
-igor
On 5/14/07, Johan Compagner [EMAIL PROTECTED] wrote:
nope.. its just a hashmap!
johan
On 5/14/07, Igor
I'm not sure if this is related issue, but here it goes:
I have a bookmarkable page with page parameters that is mounted using
QueryStringUrlCodingStrategy. If I open a link to this page in a new browser
window, it works fine. However, if I try to open the same link in another
tab, wicket
but you see how this leads to inconsistencies right? all of a sudden some
things are arrays (params coming from request) while others are not (params
we put in). so its messy.
The thing that was messy was the old version of Wicket trying to be
smart with those parameters, which resulted in the
well, its still messy unless you override map.put and wrap things that are
not an array in one.
-igor
On 5/14/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
but you see how this leads to inconsistencies right? all of a sudden
some
things are arrays (params coming from request) while others
well, its still messy unless you override map.put and wrap things that are
not an array in one.
Blame the servlet API for that. I don't think we should 'fix' their
bad choice (as yes, what we had was indeed nicer, but just
inconsistent and because of that got people into trouble).
It sounds
i am not saying we shouldntve fixed it to return an array always, what i am
saying is that it is inconsistent because when we put things into that map
we dont wrap them in an array, and we should, no? why is that map mutable?
-igor
On 5/14/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
well,
Hi, Eelco,
I did a short example, a simple (without much complexity, as the
original page has) page2page flow by bookmarkable link, passing 2
parameters, but it's working the right way!? it's not converting
String to String[] parameters.
Strange behaviour... because the phenomenon is actually
Hi,
I've had a look into this.
String parameters in the servlet-api spec are String arrays, so that you
can go:
?color=redcolor=greencolor=blue
...and expect to get String[] color = String { red, green, blue };
This is why we have convenience methods for you (as does servlet-api).
Construct
* Al Maw:
This behaves properly with both mounted BookmarkablePages, and
also unmounted ones.
Hi Al, we're only talking about 1.2.6 in this thread. There
appears to be a regression or incompatibility between 1.2.5 and
1.2.6.
See:
ClassCastException in WebRequestCodingStrategy
Dear Sirs,
I updated to Wicket 1.2.6 and I have found the following behavior when
using BookmarkablePageLink (which was not happening before in Wicket
1.2.5). The code example is:
private class Link1 extends BookmarkablePageLink {
private static final long serialVersionUID = 1L;
i don't know exactly, but i think the change was made because returning a
String[] is how it's in the spec.
please correct me if i'm wrong or have the wrong conversation in mind.
gerolf
On 5/8/07, manu [EMAIL PROTECTED] wrote:
Dear Sirs,
I updated to Wicket 1.2.6 and I have found the
Yep. Something like that. Manu, could you please provide me with a
unit test showing your problem? I'd be happy to fix if I have one. I'm
currently waiting on someone else sending us a test for a related
problem.
Cheers!
Eelco
On 5/8/07, Gerolf Seitz [EMAIL PROTECTED] wrote:
i don't know
24 matches
Mail list logo
