yeah
it looks like you are also getting form submit parameters and the indexed
strategy cannot encode them because their names are not integers
this is the trouble with the indexed strategy
not sure how to go about fixing it
you dont have a query string because the params are part of the path
what you have to do is somehow figure out what the mount is, subtract that
from the path and then split the remainder on "/" and create the array of
parameters, then add those to pageparameters
-Igor
On 10/27/06, Korbinian Bachl <[EMAIL PROTECTED]> wrote:
Hi Igor,
i already tried this before posting, but when i do it, i get an error:
code:
@Override
public void onSubmit()
{
String suchFeld = getSuchfeld();
if(suchFeld.length()>0)
{
PageParameters params = new PageParameters();
params.add("finde",suchFeld);
setResponsePage(Suche.class,params);
}
else
{
setResponsePage(getPage().getClass(),new
PageParameters(getRequest().getRequestParameters().getParameters()));
}
}
if i call it with content all is fine, if i try to call without content
and
it steps into the else it gives an error:
wicket.WicketRuntimeException: Not all parameters were encoded. Make sure
all parameter names are integers in consecutive order starting with zero.
Current parameter names are: [suchen, SuchPanel_suchForm:hf:0, suchFeld]
this happens in a panel holding a simple search form (1 textfield + submit
button)
any idea ?
> -----Ursprüngliche Nachricht-----
> Von: Igor Vaynberg [mailto:[EMAIL PROTECTED]
> Gesendet: Freitag, 27. Oktober 2006 20:34
> An: [email protected]
> Betreff: Re: my Feature Request/ Idea + now proposal (nice URLs)
>
> On 10/27/06, Korbinian Bachl <[EMAIL PROTECTED]> wrote:
> >
> > i did and i got it working - however, one thing confuses
> me: if i now
> > have this params:
> > /foo/bar/xxx
> > and i have a panel there holding a form that wants to
> recall this same
> > URL, how would i achive this ?
> > e.g:
> > ResponseParameters p = getMeThoseParams();
> > setResponsePage(getPage().getClass(),p);
>
>
> hmm how about
> new
> PageParameters(getRequest().getRequestParameters().getParameters());
>
> that will also filter out any wicket-specific params in the
> url that you might get if you just do new
> PageParameters(getRequest().getParameterMap());
>
> -Igor
>
>
>
>
>
>
>
>
>
> Best Regards,
> >
> > Korbinian
> >
> > >
> > > ok, this enhances the "Igor made my Day!" level by 1 to a
> sum of 2
> > > :P
> > > >
> > > > thanks
> > > >
> > > >
> > > >
> > > > > -----Ursprüngliche Nachricht-----
> > > > > Von: Igor Vaynberg [mailto:[EMAIL PROTECTED]
> > > > > Gesendet: Freitag, 27. Oktober 2006 19:40
> > > > > An: [email protected]
> > > > > Betreff: Re: my Feature Request/ Idea + now proposal
> (nice URLs)
> > > > >
> > > > > this is already implemented :) see
> IndexedParamUrlCodingStrategy
> > > > >
> > > > > whether it should be made default or not is another
> discussion.
> > > > >
> > > > > -Igor
> > > > >
> > > > >
> > > > > On 10/27/06, Korbinian Bachl <[EMAIL PROTECTED]> wrote:
> > > > > >
> > > > > > Hi All,
> > > > > >
> > > > > > i have read the posts regarding my idea/ request and
> > > > > understand both
> > > > > > sides.
> > > > > > I understand Eelcos and my (plus others) needs for premade
> > > > > > enhancements, but i also understand Igors and
> Martinjs point
> > > > > > in regarding the API. In fact it scared me a bit
> that it got a
> > > > > such big
> > > > > > discussion, and im at a point where im not sure myself what
> > > > > the right
> > > > > > way is, and im adding a +0.5 from my side for it,
> > > because i still
> > > > > > think the advantages are bigger with it.
> > > > > >
> > > > > > Another thing that came into my mind again was the
> request for
> > > > > > nice URLs i made some time ago. I now understand
> that my basic
> > > > > idea at that
> > > > > > point would not work with wicket and as im getting deeper
> > > > > into wicket
> > > > > > & java i also realised that its not easy, however others
> > > > > need this as
> > > > > > well much (see posts in main wicket mailinglist).
> > > > > >
> > > > > > Ive worked the last week on different URL strategies
> > > and stumbled
> > > > > > often in problems regarding the independence of components,
> > > > > and think
> > > > > > i might have at least a better solution as we have now.
> > > > > >
> > > > > > What i have in mind is that we might want to change the way
> > > > > > pageParameters are implemented. Currently you can mount a
> > > > > page to e.g:
> > > > > > /testpage and then use param Say = hello, to =
> wicket to get
> > > > > > /testPage/Say/hello/to/wicket
> > > > > >
> > > > > > now this is nice and ok, but wouldnt it be better
> to just have
> > > > > > /testpage/hello/wicket ??? so URLs would be shorter,
> > > could be more
> > > > > > "flexible" and it they would exactly contain what the app
> > > > > developer wants.
> > > > > >
> > > > > > The trick here would be to change the way we have
> > > > > PageParameters away
> > > > > > from a map to a array like way (or even queue like). e.g:
> > > > > instead of
> > > > > > having
> > > > > > params.set("Say","hello") this would just be
> > > > > params.add(hello) - and
> > > > > > since we know hello is 1 st we have the key - we dont need
> > > > > a string as
> > > > > > a key representing "say" as we know its just array 1 - this
> > > > > would make
> > > > > > it easier to introduce tree like URL structures as well
> > > as it gets
> > > > > > closer to the URL itself (unique) -> e.g:
> > > > > > /testpage/to/wicket/say/hello wouldnt work anymore, and
> > > > > since we know
> > > > > > the exact position of each parameter we could even use
> > > > > ACEGI / or JEE
> > > > > > url security with this.
> > > > > >
> > > > > > Please let me know what you think about this - i think this
> > > > > might be a
> > > > > > doable solution to help the needs of nice URLs as well
> > > as security
> > > > > > based on paths.
> > > > > >
> > > > > > Best Regards,
> > > > > >
> > > > > > Korbinian
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > >
> >
> >
>
