* Korbinian Bachl:
These was aimed at the missing decoding of these issues in
pageparameters, however, I now wonder if it wouldnt be better to
give wicket a common URL filter wich decodes and encodes all
URLs before they are used/ released so that these are solved
forever.
Hi,
I notice after upgrading from wicket 1.2 to current wicket-1.x
that replaceWith() combined with an AjaxRequestTarget does not
work anymore. I recall that you added smart markup ids with auto
increments.
So what I propose is to add to the migrate-1.3 wiki page the
following,
sounds very promising - like i wrote to eelco: if all URL things would be
centralised and go through 1 place at the end (encode)/ begining (decode)
then the world would be open to handle most special url needs easier - e.g:
language-tag in URLs, global needed params etc.
as it could go this
Reqeust.encodeUrl is the common base point where all urls are going
through. But you also want a decode place where the incomming url
(that can be any thing then, first passes through?)
On 11/26/06, Korbinian Bachl [EMAIL PROTECTED] wrote:
sounds very promising - like i wrote to eelco: if all
our replace methods should migrate the id imho. please add an rfe.
-igor
On 11/26/06, Jean-Baptiste Quenot [EMAIL PROTECTED] wrote:
Hi,
I notice after upgrading from wicket 1.2 to current wicket-1.x
that replaceWith() combined with an AjaxRequestTarget does not
work anymore. I
yeah - thats my thought
i mean encoding is useless as long as we have no common decoding gateway,
right?
imagine, that you can build a wicket app where you can put additional info
into the url just before the app-root itself...
e.g:
site/mountpoint
site/additionalthings/mountpoint
without
Could someone please take a look at what's wrong with Wicket 2.0's
unit tests? Besides the fact that we have 5 failures and 2 errors,
they generate an enormous amount of serialization errors.
Eelco
