Re: Implementing Tiles Request (2/3): Calling an alien API

[Mick Semb Wever <mc...@apache.org>]

> > It's some extra work at coding, but it doesn't interfere with the
> > loading of the initial template, so the testing and debugging should be
> > easier. 
> 
> It sounds about right yes. I'll take a closer look at
> DeferringMustacheFactory.

Maybe i'm blind but i can't see any satisfactory solution here.
The visitor pattern provides the "deferring" functionality, and that is
only for the rendering of the partial, not the load/compile of it.

What we are trying to do is add a context to MustacheFactory where one
previously doesn't exist, a hint that lambdas are better suited.
It would be better if the definition name was also explicit in the
partial, eg {{>definitionName/attributeName}} but in practice often you
would want definitionName to be relative, ie the current definition.


> > 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.

Indeed we're working on that problem.
AttributeContext provides what we want.

Our first attempt is simply to dump all attributes as a
Map<String,Object> into the request scope under the name "tiles" (in a
subclass of the MustacheRenderer). But this might not work so smoothly
client side.

Which brings us back to lambdas, as they might be easier to implement
with one javascript library than to provide examples on how to make the
client-side stuff compatible…
(lambdas weren't our first approach as they were in mustache java 0.6).

Either way the server must provide a url that returns a json object
holding all tiles attributes. But that is easy enough to demonstrate how
to do.

~mck


-- 
"A mind that has been stretched will never return to its original
dimension." Albert Einstein 

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

Re: Implementing Tiles Request (2/3): Calling an alien API

[Nicolas LE BAS <ma...@nlebas.net>]

On 12-09-04 03:43 AM, Mck wrote:
>> And/or about implementing
>> a tiles-like framework on the client side? Could you provide a basic
>> example? 
> 
> On the client side you can override how the loading of partials works,
> and implement lambdas yourself in javascript.

> So a mustache template renders either on the server or the client.
> The idea then could be to write two new autotag implementations, one for
> Google Functions (which mustache server uses), and one for javascript.

Autotag is currently focused on java. It could generate javascript code
easily instead of java, but the generated code is only some glue between
the alien API and the actual implementation of the tags (see
tiles-template). I have a hard time thinking how we could compile those
into javascript.

> Whether the javascript implementation is built upon the autotag or is
> just a standalone library mimicing what's needed i'm still unsure of.
> The javascript library will require certain URLs against the server.
> Like give me a template, give me a Definition/AttributeContext, etc. In
> practice we will also want to bundle much of this all into one URL so
> the client-side tiles doesn't become too chatty. Of course this these
> URLs must be implemented by all from scratch even if we can provide good
> example and/or helper classes/servlets.

I think you've been describing the solution in some detail, but the
problem that it solves is still fuzzy in my head.

>From an architect's point of view, the minimal list of inputs of the
Tiles engine is short enough:
- A set of templates
- A set of definitions
- A path
- A set of scoped "Request" attributes

It looks easy enough to send a copy of the templates and definitions to
the browser. Providing the path is no issue.

The set of attributes is another matter, and raises a number of concerns:
- Do we want the whole process to happen in the browser, i.e. the
initial rendering and the reloading of a fragment? Or only the
reloading, and then we need two identical rendering stacks in java and
javascript?
- Can we (technically) expose all the attributes to the browser?
- Do we dare to expose them ? (security concern: how do we handle roles?)
- If we're only reloading a fragment, how do we deal with the attributes
that are cascaded from the enclosing definition?
- If we use attributes from multiple scopes (for instance, session), how
do we keep them up to date? (for instance, what if the user opens
multiple tabs to the webapp?)

We likely can answer the questions above by limiting the use cases. Just
how limited would they be, that is the question...

Re: Implementing Tiles Request (2/3): Calling an alien API

[Mck <mc...@apache.org>]

> > Maybe i'm blind
> Wow wow wow...

;)
just a friendly way to ask if i was missing something...


> Could you explain a bit? Is this about replacing a part of the web page
> dynamically after an AJAX call, for instance? 

Yes.

> And/or about implementing
> a tiles-like framework on the client side? Could you provide a basic
> example? 

On the client side you can override how the loading of partials works,
and implement lambdas yourself in javascript.

So a mustache template renders either on the server or the client.
The idea then could be to write two new autotag implementations, one for
Google Functions (which mustache server uses), and one for javascript.

Whether the javascript implementation is built upon the autotag or is
just a standalone library mimicing what's needed i'm still unsure of.
The javascript library will require certain URLs against the server.
Like give me a template, give me a Definition/AttributeContext, etc. In
practice we will also want to bundle much of this all into one URL so
the client-side tiles doesn't become too chatty. Of course this these
URLs must be implemented by all from scratch even if we can provide good
example and/or helper classes/servlets.

~mck

Re: Implementing Tiles Request (2/3): Calling an alien API

[Nicolas LE BAS <ma...@nlebas.net>]

On 12-09-01 01:36 AM, Mick Semb Wever wrote:>
> Maybe i'm blind [...] visitor pattern [...] add a context to
MustacheFactory [...]

Wow wow wow... Just because my one-liner explanation is missing an
example doesn't mean you're blind. Forget about MustacheFactory for a
while, the point is to implement the algorithm in PartialCode, because
it doesn't require the addition of anything.

But I agree that lambdas may be the way to go, especially since partials
look awkward and invasive in mustache.js, so let's focus on that.

> Our first attempt is simply to dump all attributes as a
> Map<String,Object> into the request scope under the name "tiles" (in a
> subclass of the MustacheRenderer). But this might not work so smoothly
> client side.

Looks like it's doing the job, though.

But I'm not sure exactly what you're trying to achieve with all that
"client-side" thingies... you're months ahead of me on that subject.

Could you explain a bit? Is this about replacing a part of the web page
dynamically after an AJAX call, for instance? And/or about implementing
a tiles-like framework on the client side? Could you provide a basic
example?