The reason I wrote the session cache was to support clustering. The data
uri would solve that problem also. Before data attributes I found it useful
because it made some things much simpler than the Tapestry 5.3 way of doing
things. Since you can put scripts in the tml file you can use properties to
populate the scripts so each script is customized to the user. Simple
example in your tml file:
<script>
alert("hello ${user}");
</script>
This would be converted to a script file with a url. If you could make it
work like an event link that returned javascript from the page you don't
even need the cache. I've though about implementing that but never started
(this also solved the clustering problem and you don't need a cache).
With Tapestry 5.3 things like this required a lot of code. 5.4 is better
but still requires an extra javascript file.
On Wed, Feb 5, 2014 at 7:37 AM, Lance Java <lance.j...@googlemail.com>wrote:
> But would we actually be solving anything? Or are we just ticking a box :)
> On 5 Feb 2014 13:34, "Thiago H de Paula Figueiredo" <thiag...@gmail.com>
> wrote:
>
> > On Wed, 05 Feb 2014 11:26:11 -0200, Lance Java <
> lance.j...@googlemail.com>
> > wrote:
> >
> > Any thoughts on using a data uri?
> >>
> >
> > Good catch, Lance. Supposing browsers support it, and I don't know the
> > answer, it would be the ideal solution.
> >
> > --
> > Thiago H. de Paula Figueiredo
> > Tapestry, Java and Hibernate consultant and developer
> > http://machina.com.br
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> > For additional commands, e-mail: users-h...@tapestry.apache.org
> >
> >
>
