scalate, GAE and pre-compiling the templates
James Strachan
http://n3.nabble.com/scalate-and-GAE-td422553.html#a422553
so thought I'd spin it up here for good measure.
So using scalate on GAE is gonna cause issues as it probably takes a
while right now for Scala to compile the templates from source the
first time they are used (its a little slow the scala compiler these
days) and GAE might kill the servlet before its compiled the template.
So we probably want to compile all the templates first before you
deploy on production - just in case.
This general approach is probably a good thing in general anyway;
compile all your templates as part of your build for production (or
load testing or functional testing or whatever). Not only does it make
your application fly, it catches any possible bugs early. Compiling
each template lazily as its required and whenever it changes works
great in development though.
The current default in Scalate is to look at the source and the
generated class (in WEB-INF/_scalate by default) and only
regenerate/recompile the template's class if there is a change. I
wonder if we need a 'production mode' setting where we'll just use the
current compiled version anyway - just in case some strangeness occurs
with timestamps on files?
We also need to be able to pre-compile all the *.ssp and *.scaml
templates in your web app as part of the build process. There was a
pretty early issue for this...
http://fusesource.com/issues/browse/SCALATE-3
I've just spun up another for folks who use sbt or Ant build systems..
http://fusesource.com/issues/browse/SCALATE-37
http://fusesource.com/issues/browse/SCALATE-38
--
James
-------
http://macstrac.blogspot.com/
Open Source Integration
http://fusesource.com/
Hiram Chirino
--
Regards,
Hiram
Blog: http://hiramchirino.com
Open Source SOA
http://fusesource.com/
Paul Sandoz
On Mar 4, 2010, at 6:26 PM, Hiram Chirino wrote:
> Going to take a crack at a maven plugin to help with this.
>
+1 for a maven plugin.
Paul.
James Strachan
> Going to take a crack at a maven plugin to help with this.
Great stuff!
Am sure once we've something working for Maven, folks using other
stuff can easily create similar versions of it (reusing hopefully most
of the guts of it)
phausel
would be to pre-render all templates in play's runtime context (due
to our special Context and binding setup), which sometimes won't be
possible without some interaction (ie logging in etc.), so it seems
definitely more involved than I originally hoped.
On Mar 4, 12:30 pm, James Strachan <james.strac...@gmail.com> wrote:
Hiram Chirino
The initial cut of the maven plugin is checked in.
Here's an example of how it can be added to a pom as a profile:
http://github.com/scalate/scalate/blob/master/scalate-bookstore/pom.xml#L136
This allows you to add the "-P precompile" to the maven command line
to enable scalate template precompiling.
If someone gets a chance could they verify that when precompiled
templates are in the classpath, the TemplateEngine avoids compiling
the templates again at runtime? I theory it should work, but we don't
have unit tests for that yet.
Regards,
Hiram
James Strachan
> I was also thinking about this and I believe the only real way for us
> would be to pre-render all templates in play's runtime context (due
> to our special Context and binding setup), which sometimes won't be
> possible without some interaction (ie logging in etc.), so it seems
> definitely more involved than I originally hoped.
TemplateEngine's can be customized with different bindings for
different frameworks like servlets, Jersey, Play etc. I wonder if each
framework had its own TemplateEngine class - e.g. PlayTemplateEngine -
could the precompiler just be configured in the pom.xml with the
specific template engine class to use?
To compile the template (or at least to generate the .scala file for
it) - we'd just need to know the specific bindings that a framework
adds right? We don't need a runtime instance of the play framework do
we? If not I guess different frameworks could also have their own
versions of the precompiler; worst case we could just boot up the real
app, and generate all the template classes inside the real app :)
Hiram Chirino
example the ServletTemplateEngine requires a ServletConfig as a
constructor arg.
Obviously I can't supply one of those in maven.
Regards,
Hiram
--
phausel
that we add bindings depending on what parameters the controller is
passing in. So I think you can not compile a scalate template without
providing those bindings for a given template.
for example:
<%= name %>
the binding for this template is determined dynamically (ie the
controller is passing the variable name + value to scalate and
scalate
adding a binding for "name" before rendering the template)
On Mar 4, 2:21 pm, James Strachan <james.strac...@gmail.com> wrote:
> On 4 March 2010 18:07, phausel <peter.hau...@gmail.com> wrote:
>
> > I was also thinking about this and I believe the only real way for us
> > would be to pre-render all templates in play's runtime context (due
> > to our special Context and binding setup), which sometimes won't be
> > possible without some interaction (ie logging in etc.), so it seems
> > definitely more involved than I originally hoped.
>
> TemplateEngine's can be customized with different bindings for
> different frameworks like servlets, Jersey, Play etc. I wonder if each
> framework had its own TemplateEngine class - e.g. PlayTemplateEngine -
> could the precompiler just be configured in the pom.xml with the
> specific template engine class to use?
>
> To compile the template (or at least to generate the .scala file for
> it) - we'd just need to know the specific bindings that a framework
> adds right? We don't need a runtime instance of the play framework do
> we? If not I guess different frameworks could also have their own
> versions of the precompiler; worst case we could just boot up the real
> app, and generate all the template classes inside the real app :)
>
> --
> James
Hiram Chirino
I'm not sure that it's safe to define implicit bindings using dynamic variables.
If it's dynamic, how do you ensure that the same implicit variables are defined
every time the template is rendered?
I could see cases where if variable is not set, perhaps you don't
generate an implicit binding that the template file is expecting.
Regards,
Hiram
--
James Strachan
> Hi Peter,
>
> I'm not sure that it's safe to define implicit bindings using dynamic variables.
> If it's dynamic, how do you ensure that the same implicit variables are defined
> every time the template is rendered?
>
> I could see cases where if variable is not set, perhaps you don't
> generate an implicit binding that the template file is expecting.
I guess if a template is only used by one controller and the
controller sets up the bindings used by the template, it'll work fine
- provided noone from another template includes that template.
From a Scalate perspective I guess its up to the user of the template,
controller and template engine instance to ensure things all work out
OK - or give reasonable error messages.
From an IDE perspective (imagine if we had an IDE plugin for say, SSP
templates), it'd be really nice if a template was a stand alone thing.
i.e. from the template itself (and knowing what framework it was being
used with maybe), an IDE or compiler could know what variables were in
scope and what types they were - so it could do proper
completion/error detection etc.
e.g. from Peter's example, image if a template displayed a name and value...
<%@ val name : String %>
<%@ val value : List[Int] = Nil %>
<p>hello ${name} the value is ${value}</p>
this template is stand alone; an IDE could smart complete all
expressions & method navigations while editing and be able to spot
scala compile errors and so forth. At runtime if you don't pass in
either value you'll get a nice meaningful error message (if we've not
specified default values) - even if you do an include from anywhere or
from another servlet or whatever.
However if there are a lot of variables; it can be a PITA passing them
all in by hand. Its also not very DRY. In things like Jersey implicit
views (and a few other MVC frameworks like Spring MVC) there is often
a single 'model object' (which might be the controller itself) which
tends to own all the various bits of data. So if we had this 'model'
package cheese
case class Foo(name: String, value: String)
then you're view would just need a single variable declaration...
<%@ import val foo : Foo %>
<p>hello ${name} the value is ${value}</p>
however if you used a naming convention; such as the above template
being called cheese/Foo.index.ssp then you could make that first line
implicitly defined. i.e. deduce in a stand alone way the implicit
imports of the template, then this template could render...
<%-- I work if named cheese/Foo.*.ssp --%>
<p>hello ${name} the value is ${value}</p>
This works well for things like Jersey; however when the controllers
tend to be stateless in Play (from my limited knowledge) its maybe not
so easy to do this kind of thing?
So many frameworks, so many ways of doing things I guess. (Lift is
even more different in that there's typically no context and you pull
stuff in inside the template - but then thats more straightforward in
a way as you just import what you want).
I wonder if there's a way in Play, the way the Play Scala + Play
Scalate work together to introduce some naming or code convention of
sorts so you could in effect auto-import all the variables passed from
the controller but in way thats introspectable - at runtime, at build
time and at IDE edit time?
I'm wondering if for a given combination of scalate + framework, we
can create a BindingStrategy which for a given template URI will be
able to generate the implicit bindings that are required to compile
it? If so then we can pre-compile the templates ahead of time. Note
its not the end of the world if not; it could just be for some
frameworks we can't pre-compile templates ahead of time? Or we only
precompile them by running the actual framework with the controller?
(And maybe by actually running the controller we could generate the
necessary metadata somewhere that an IDE plugin could use? :)