You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tiles.apache.org by Nicolas LE BAS <ma...@nlebas.net> on 2012/08/29 20:01:06 UTC

Implementing Tiles Request (3/3): In an alien environment

... Continued from previous message

* Using the Request interface from an alien environment.

  This happens mostly when implementing AutotagRuntime<Request>. You
receive some information from the alien environment and have to build a
Request object from it.

  The main difficulty is analyzing the alien environment. Let's take
velocity for example: you're sitting in a directive (a tag) in the
middle of a template, and you've received a Context object, that in
itself lacks 50% of the features of the Request API. I couldn't find a
good solution to that.

  One way is to adopt one use case (i.e. VelocityView) and support that
use case alone.

  Another way that is advocated by Antonio is to lobby the other project
into adopting the Request API...

  The last way is to try and find out which use case you're processing
and react accordingly. But then you have to compromise between requiring
additional dependencies and slowing things down by using reflexion and
dynamic class loading, which can be touchy and difficult to support in
the long term.

  JSP uses the first approach (use from a servlet container only), and
Freemarker has been easy enough because their API supports most of what
we need. I'm trying the third approach with Velocity but I can't say I'm
satisfied with it.

Comments welcome...

Re: Implementing Tiles Request (3/3): In an alien environment

Posted by Mick Semb Wever <mc...@apache.org>.
On Wed, 2012-08-29 at 14:01 -0400, Nicolas LE BAS wrote:
>   One way is to adopt one use case (i.e. VelocityView) and support that
> use case alone.
> 
>   Another way that is advocated by Antonio is to lobby the other project
> into adopting the Request API...
> 
>   The last way is to try and find out which use case you're processing
> and react accordingly. But then you have to compromise between requiring
> additional dependencies and slowing things down by using reflexion and
> dynamic class loading, which can be touchy and difficult to support in
> the long term.
> 
>   JSP uses the first approach (use from a servlet container only), and
> Freemarker has been easy enough because their API supports most of what
> we need. I'm trying the third approach with Velocity but I can't say I'm
> satisfied with it.
> 
> Comments welcome... 


I read this as best is to  
a) lobby the other project up front, and
b) live with a "adopt one use case" solution in the meantime.

~mck

-- 
“Problems cannot be solved by the same level of thinking that created
them.” - Albert Einstein 

| http://github.com/finn-no | http://tech.finn.no |