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