On Wed, 24 Dec 2014 20:09:53 -0200, Dmitry Gusev <dmitry.gu...@gmail.com>
wrote:
Hi,
as far as I know, Tapestry's URLEncoder allows you to not think about
encoding, it forces to UTF-8.
Yep. In addition, it encodes and decodes null and empty string values,
something java.net.URLEncoder doesn't do, but Tapestry needs for
activation context.
Tapestry's URLEncoder is a service as any other, so you can easily
override, decorate or advise according to your needs. I'd just suggest you
to take a look at how the default implementation works before implementing
your own.
Default URLEncoder asks you to specify encoding as a separate parameter,
which you normally pass as another URL parameters, for example, look at
ie/oe parameters that Safari adds to Google request URL when you search
from Safari's address bar:
https://www.google.com/search?client=safari&rls=en&q=help&ie=UTF-8&oe=UTF-8
On Wed, Dec 24, 2014 at 11:22 PM, George Christman
<gchrist...@cardaddy.com>
wrote:
Hi guys, I'm just wondering why Tapestry decided to build their own
URLEncoder over using an existing one like java.net.URLEncoder? I'd
like to clean up my URLs removing a lot of the encoding making them
more search friendly, so I'm wondering what the impact of overriding
the URLEncoder service and implementing a more standard one would be?
Thanks.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
