You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Fernando Bellas Permuy <fb...@udc.es> on 2009/03/06 17:34:45 UTC

Encoding in activation context

Hi!

I am implementing a simple service that returns XML (a RESTful service 
invoked by GET) as a Tapestry 5 page. That is, the associated template 
(.tml) does not return HTML/XHTML, but XML. I have used the @ContentType 
annotation on the page class: @ContentType("text/xml"). All is working 
fine. To my understanding, Tapestry does not provide any specific 
support to implement this kind of services. However, the usual page 
support should be enough for GET/POST requests (I am only interested in 
GET requests by now).

The page has an activation context. The activation context represents 
the parameters of my service. To simplify my question, consider that the 
service requires two parameters: category and keywords. Since Tapestry 
embeds the activation context inside the URL's path, to invoke my 
service by GET, the client must make a call to a URL like:

http://.../myservice/<<category>>/<<keywords>>

e.g. (category=40, keyworkds=Java)

http://.../myService/40/Java

Let us suppose "keywords" contains blank characters, like for example 
"The Java Programming Language"

Experimentally, I have observed that the client must use the following URL:

http://.../myService/40/The$0020Java$0020Programming$0020Language

That is, blank characters must be replaced by $0020. Other non-English 
characters (e.g. latin characters like ñ, á, etc.) must be encoded.

I understand that Tapestry encodes the activation context by using 
org.apache.tapestry5.services.URLEncoder. Does this class follows some 
standard encoding mechanism? - In my case this is necessary, since the 
client is not Java, but .NET.

Should Tapestry use RFC 2396, as java.net.URI does?

Any advice for my client code?

Any other strategy to implement an XML service in Tapestry?

Thanks!

-- 
Fernando Bellas Permuy

Associate Professor (Titular) at University of A Coruña
Department of Information and Communications Technologies
Facultad de Informática - Campus de Elviña, S/N
15071 - A Coruña - Spain
http://www.tic.udc.es/~fbellas - fbellas@udc.es
Tel: +34 981 167 000 (ext: 1353) - Fax: +34 981 167 160

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: Encoding in activation context

Posted by Fernando Bellas Permuy <fb...@udc.es>.
Hi!

Finally, I have been able to adopt an standard solution by injecting the 
"Request" service in the page implementing the service. It is very easy.

Example:

public class MyService {

    // ...
	
     @Inject
     private org.apache.tapestry5.services.Request request;
	
     void onActivate() {

         String keywords = "";

         if (request.getParameter("keywords") != null) {
             keywords = request.getParameter("keywords");
         }

         // ...

     }

     // ...
		
}

The service may be invoked by GET by using the URL:

http://.../myservice?keywords=value1&anotherParameter=value2&...

e.g.

http://.../myservice?keywords=The+Java+Programming+Language&anotherParameter=value2&...

That is, parameters are not coded in the activation context, but as 
normal HTTP parameters. This is a common solution for RESTful services 
(even though not mandated by the RESTful architectural approach). 
Parameters must be encoded in the client-side as specified by 
"application/x-www-form-urlencoded" MIME format (e.g. 
java.net.URLEnconder.enconde(value, "UTF-8") for a Java client). For 
example, blank spaces must be replaced by "+" characters.

I have not checked it, but it should be possible to access HTTP 
parameters this way not only for GET requests but also for POST, PUT, 
and DELETE (for POST requests, of course, parameters are inside the 
request body and not in the URL, but this is transparent for the service).

Thanks.

-- 
Fernando Bellas Permuy

Associate Professor (Titular) at University of A Coruña
Department of Information and Communications Technologies
Facultad de Informática - Campus de Elviña, S/N
15071 - A Coruña - Spain
http://www.tic.udc.es/~fbellas - fbellas@udc.es
Tel: +34 981 167 000 (ext: 1353) - Fax: +34 981 167 160

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: Encoding in activation context

Posted by Marcus Veloso <mv...@gmail.com>.
Hi Fernando,
Maybe this help.
http://code.google.com/p/t5-restful-webservices/

Cheers,

Marcue Veloso

Re: Encoding in activation context

Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Fri, 06 Mar 2009 13:34:45 -0300, Fernando Bellas Permuy  
<fb...@udc.es> escreveu:

> Hi!

Hi!

> Experimentally, I have observed that the client must use the following  
> URL:
> http://.../myService/40/The$0020Java$0020Programming$0020Language

This encoding is done by the org.apache.tapestry5.services.URLEncoder  
service. You can write your own and override the default Tapestry one  
using alias overrides:  
http://tapestry.apache.org/tapestry5/guide/alias.html.

> Should Tapestry use RFC 2396, as java.net.URI does?

Until some minor versions ago, that's what Tapestry used. Maybe it should  
present some easy way to choose one or another.

-- 
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org