tiles-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas LE BAS <m...@nlebas.net>
Subject Re: Implementing Tiles Request (2/3): Calling an alien API
Date Fri, 31 Aug 2012 15:58:30 GMT
On 12-08-31 10:47 AM, Mick Semb Wever wrote:
> We're still working our way through things (it's important that
> including partials by tiles attribute names works both client and server
> side), it may well be that we use lambdas instead of partials... and
> that leads to implementing an autotag implementation against lambdas.

I was thinking of implementing something (a DefinitionRenderer?) that
evaluates all the definition attributes first, and delivers the results
as request attributes (through a RequestWrapper, and possibly an extra
scope "definition") before calling the definition template.

I think that would cover the "lambda" scenario for mustache (on the
server side), and it would be useful if we want to add caches and
decorators into the tiles framework, too. And we've had users calling
for evaluating the attributes in a specific order.

> But regardless of the partials we do want a way where resource loading
> goes through the application context, and we also don't create a very
> specific set of mustache classes that can only be used. But this relates
> back to your discussion in (3/3) where often only one use-case can be
> supported.

that part looks easy enough to me:

public class ContextMustacheFactory extends DefaultMustacheFactory {
   private ApplicationContext context;
   public ContextMustacheFactory(ApplicationContext context) {
     this.context = context;
   }

  @Override
  public Reader getReader(String resourceName) {
    // TODO check for NPEs and actual resourceName syntax
    return new BufferedReader(new
InputStreamReader(context.getResource(resourceName).getInputStream(),
Charset.forName("utf-8")));
  }
}

Mime
View raw message