view() questions
Jon DeYoung
I've been hacking away with scalate the past week or so, and with only
a little pain I managed to get it playing nice with spring mvc. I
have to say, I like it a lot, keep up the good work!
I really like the "views" feature (http://scalate.fusesource.org/
documentation/user-guide.html#views), but I've run into a few issues:
1) Invalid views (where no matching template is found) are silently
ignored. I make a lot of typos, so I think and exception should be
thrown in this case.
2) The base path for templates is not is not (easily) configurable
when using the view() call, or at least I can't figure out how to do
it :). I like to keep my templates in a separate directory, and
possibly have multiple template directories.
And a quick suggestion:
I've used a similar mechanism in the past and I found it very helpful
to have some HTML comments indicating the start / end of a view when
debugging template issues... Otherwise it can be a PITA to track down
exactly which template is causing the problem. Something like the
following (which can be turned on/off via a flag):
...
<!-- [START template=/MyClass.head.scaml -->
...
<!--[END template=/MyClass.head.scaml -->
...
I've done this locally by overriding the ServletRenderContext, but
maybe it would be useful for others?
Cheers
Jon
James Strachan
On 15 September 2010 00:00, Jon DeYoung <jdey...@gmail.com> wrote:
> Hey Guys
>
> I've been hacking away with scalate the past week or so, and with only
> a little pain I managed to get it playing nice with spring mvc.
Great stuff! I wonder if we should add a little spring mvc sample to
the scalate distro; then we can try fix those problem areas?
> I
> have to say, I like it a lot, keep up the good work!
Thanks!
> I really like the "views" feature (http://scalate.fusesource.org/
> documentation/user-guide.html#views), but I've run into a few issues:
>
> 1) Invalid views (where no matching template is found) are silently
> ignored. I make a lot of typos, so I think and exception should be
> thrown in this case.
Good idea! I've raised an issue to track it...
http://scalate.assembla.com/spaces/scalate/support/tickets/158
> 2) The base path for templates is not is not (easily) configurable
> when using the view() call, or at least I can't figure out how to do
> it :).
Currently it defaults to using the directory passed into the
constructor of the TemplateEngine.
> I like to keep my templates in a separate directory, and
> possibly have multiple template directories.
As an aside; I've recently made a minor refactor so that you can
create a TemplateEngine with a List[File] of sourceDirectories so you
can specify each directory you want to use to search for templates.
> And a quick suggestion:
>
> I've used a similar mechanism in the past and I found it very helpful
> to have some HTML comments indicating the start / end of a view when
> debugging template issues... Otherwise it can be a PITA to track down
> exactly which template is causing the problem. Something like the
> following (which can be turned on/off via a flag):
> ...
> <!-- [START template=/MyClass.head.scaml -->
> ...
> <!--[END template=/MyClass.head.scaml -->
> ...
>
> I've done this locally by overriding the ServletRenderContext, but
> maybe it would be useful for others?
Great idea! Fancy submitting a patch - or forking the repo? ;)
http://scalate.fusesource.org/contributing.html
I've created a ticket to track this
http://scalate.assembla.com/spaces/scalate/support/tickets/159
Sounds like this feature would be handy to add into the TemplateEngine
itself then it could be reused in any framework (e.g. Play Framework
doesn't use Servlets); maybe with a customisable format for the
start/end of the comments so we can have non-HTML/XML comments if need
be too (though those should definitely be the defaults).
Might be nice to auto-enable the tracing comments by adding custom
query arguments to the URL (a bit like showing/hiding the console in
dev mode)?
BTW have you tried using the Scalate Console too?
http://scalate.fusesource.org/documentation/console.html
it makes it easy to see which templates were used to generate a page
and lets you easily open the templates for editing in your editor/IDE.
Maybe another format of the 'trace comments' could be to show some
kind of visual box, template names and links to the templates? e.g. a
bit like a combination of your suggestion and the existing Scalate
Console; we could in dev mode, if enabled, show a box around sections
of the output generated by different templates - showing the template
names in the visual output along with links to the templates
themselves.
Then folks don't have to do the 'View Source' thing & grep for the
comments; they could click on a 'Highlight Templates' type link in the
Console to see which bits of output come from which template so they
know which thing to edit?
--
James
-------
http://macstrac.blogspot.com/
Open Source Integration
http://fusesource.com/
Charles F. Munat
>Something like the
> following (which can be turned on/off via a flag):
> ...
> <!-- [START template=/MyClass.head.scaml -->
> ...
> <!--[END template=/MyClass.head.scaml -->
> ...
Could this be on in DEBUG mode and off in Production mode? I like the
idea but I don't want this in my production page source.
Chas.
James Strachan
For sure. Just like the Scalate Console itself, this would only be
allowed if TemplateEngine.isDevelopmentMode is true
http://scalate.fusesource.org/maven/1.2/scalate-core/scaladocs/org/fusesource/scalate/TemplateEngine.html
Jon DeYoung
> Thanks for your feedback Jon!...
>
>
> > Hey Guys
>
> > I've been hacking away with scalate the past week or so, and with only
> > a little pain I managed to get it playing nice with spring mvc.
>
> Great stuff! I wonder if we should add a little spring mvc sample to
> the scalate distro; then we can try fix those problem areas?
>
would definitely be handy, there are probably others like me that want
to get into scala but are scared to let go of the nice warm feeling
spring gives us :) I'll fork the git repo so you can take a look at
what I have and merge it back if you want it.
> > I
> > have to say, I like it a lot, keep up the good work!
>
> Thanks!
>
> > I really like the "views" feature (http://scalate.fusesource.org/
> > documentation/user-guide.html#views), but I've run into a few issues:
>
> > 1) Invalid views (where no matching template is found) are silently
> > ignored. I make a lot of typos, so I think and exception should be
> > thrown in this case.
>
> > 2) The base path for templates is not is not (easily) configurable
> > when using the view() call, or at least I can't figure out how to do
> > it :).
>
> Currently it defaults to using the directory passed into the
> constructor of the TemplateEngine.
>
> > I like to keep my templates in a separate directory, and
> > possibly have multiple template directories.
>
> As an aside; I've recently made a minor refactor so that you can
> create a TemplateEngine with a List[File] of sourceDirectories so you
> can specify each directory you want to use to search for templates.
>
rather than working with a raw TemplateEngine. Looking at the source
I now see ServletTemplateEngine just passes the webapp root in this
list. Maybe this should configurable as well?
I think my confusion came from looking at
org.fusesource.scalate.jersey.ScalateTemplateProcessor -- this class
also maintains a list of template directories. So is this a bug in
ScalateTemplateProcessor? I think the view() call will only work in
the default case, where both expect the templates to be in /WEB-INF/
by default. Changing the template location in one of these classes
will then break the other (I noticed during my initial hacking
around).
> > And a quick suggestion:
>
> > I've used a similar mechanism in the past and I found it very helpful
> > to have some HTML comments indicating the start / end of a view when
> > debugging template issues... Otherwise it can be a PITA to track down
> > exactly which template is causing the problem. Something like the
> > following (which can be turned on/off via a flag):
> > ...
> > <!-- [START template=/MyClass.head.scaml -->
> > ...
> > <!--[END template=/MyClass.head.scaml -->
> > ...
>
> > I've done this locally by overriding the ServletRenderContext, but
> > maybe it would be useful for others?
>
> I've created a ticket to track thishttp://scalate.assembla.com/spaces/scalate/support/tickets/159
>
> Sounds like this feature would be handy to add into the TemplateEngine
> itself then it could be reused in any framework (e.g. Play Framework
> doesn't use Servlets); maybe with a customisable format for the
> start/end of the comments so we can have non-HTML/XML comments if need
> be too (though those should definitely be the defaults).
>
> Might be nice to auto-enable the tracing comments by adding custom
> query arguments to the URL (a bit like showing/hiding the console in
> dev mode)?
>
> it makes it easy to see which templates were used to generate a page
> and lets you easily open the templates for editing in your editor/IDE.
>
it sounds like I should be using it my own app. I'll give it a shot!
> Maybe another format of the 'trace comments' could be to show some
> kind of visual box, template names and links to the templates? e.g. a
> bit like a combination of your suggestion and the existing Scalate
> Console; we could in dev mode, if enabled, show a box around sections
> of the output generated by different templates - showing the template
> names in the visual output along with links to the templates
> themselves.
>
> Then folks don't have to do the 'View Source' thing & grep for the
> comments; they could click on a 'Highlight Templates' type link in the
> Console to see which bits of output come from which template so they
> know which thing to edit?
>
see how a page is sliced up.
> --
> James
> -------http://macstrac.blogspot.com/
>
> Open Source Integrationhttp://fusesource.com/
James Strachan
>> I really like the "views" feature (http://scalate.fusesource.org/
>> documentation/user-guide.html#views), but I've run into a few issues:
>>
>> 1) Invalid views (where no matching template is found) are silently
>> ignored. I make a lot of typos, so I think and exception should be
>> thrown in this case.
>
> Good idea! I've raised an issue to track it...
> http://scalate.assembla.com/spaces/scalate/support/tickets/158
This is now fixed in master. If you run the scalate-sample via "mvn
jetty:run" (which is more of an integration test web app these days
really) and try
http://localhost:8080/ssp/errors/missingView.ssp
you should see it in action