Supporting sub-directories for soy files (and other minor enhancements)

[zonski]

Hey Tom,

Pretty new to GitHub so not sure if this is the best place to put this information. Let me know if I should be posting this elsewhere.

I've been experimenting with your Google Closure + SpringMVC integration (since I was just about to write the same thing myself) for use in a project of mine. It's all working quite well (nice work) So I'm planning to continue using it in my project.

I noticed a couple of limitations for my usage, so I forked your code and made some amendments. The fork is available at:
https://github.com/zonski/spring-closure-templates

The main thing I did was update the ClosureTemplateViewResolver.compileTemplates method to search recursively through all sub-directories looking for soy files (instead of just looking one folder deep). This allows me to organise my soy files in some nicer sub-directories. I added a 'recursive' option to the configuration to disable this, but it defaults to true.

While I was there I also set the scope for servlet-api to 'provided' (servlet engines include these by default and tomcat complains if it is on the path of the war file). I also fixed a minor typo in the eclipse plugin ('downlaodJavadoc' => 'downloadJavadoc').

Feel free to merge these back into the main tree if you want them. Give me a shout if you have any questions/problems.

Thanks for your efforts in open sourcing this code. Appreciated.

zonski

[tomakehurst]

Hi,

These all seem reasonable changes, so I'm happy to merge. I suggest you open a pull request against your changes, and I'll take it from there.

Thanks,
Tom

[zonski]

Hey Tom,

I've done the pull request (first I pushed my changes, which I hadn't done).

A couple of things:

I haven't done anything to the JScript side of things (I don't use this currently) only the Java end.

Your unit tests didn't all run for me (possibly something to do with the base locations of the project directories for generated test files). I don't think this is anything I broke, but if it is let me know. I added a simple unit test for sub-directory searching.

I updated the POM version for my local use (so I could switch between yours and mine) but up to you what you want to do on your end.

I also hit another problem. Spring is sometimes adding things to the model (like BeanBindingResult) and the Soy parser obviously doesn't like these. I've not checked it in but I've currently hard coded an explicit if (!name.startsWith('org.springframework') to the renderMergedTemplate method. This is very ugly - I was wondering if you'd hit this problem and/or had any ideas on it?

[tomakehurst]

Regarding your last problem, this rings a bell, and I believe there is a config attribute somewhere to stop Spring adding additional beans to the model. I've done a bit of digging but I can't find an example of where I've seen this. I'll let you know if I find it.

I've implemented a better solution to this problem on a commercial project (which I couldn't open source unfortunately). This was to wrap all beans put into the model in a Map adapter (using reflection to expose getters as map entries), such that Soy would always treat them as valid. Again, this is one of those things I'd happily add to the project if I could find the time.

[zonski]

I don't really want to turn off Spring's Binding/Validation stuff as I think I can still use this in my templates (e.g. @Valid on my controller). I'll experiment and find out, but I think the answer is more to make the SoyViewResolver aware of Spring beans.
Funnily enough, I also just implemented a reflective ObjectToSoyMapper but I'm using it directly in my Controller (i.e. model.addObject("myBean", ObjectToSoyMapper.map(myBean))). It would make more sense to move this into the ViewResolver and then, yeah, we could do some custom handling for Spring BeanBinding. I'll put that one on the maybe-to-do list, and it will probably be something I'm forced to look at when I start looking at validation errors, etc.
Time is always the problem :) mine is always in fits and bursts on any project - lets see how much I can get done before I get pulled onto something else!

Date: Tue, 14 Aug 2012 13:13:51 -0700
From: [email protected]
To: [email protected]
CC: [email protected]
Subject: Re: [spring-closure-templates] Supporting sub-directories for soy files (and other minor enhancements) (#1)

Regarding your last problem, this rings a bell, and I believe there is a config attribute somewhere to stop Spring adding additional beans to the model. I've done a bit of digging but I can't find an example of where I've seen this. I'll let you know if I find it.

I've implemented a better solution to this problem on a commercial project (which I couldn't open source unfortunately). This was to wrap all beans put into the model in a Map adapter (using reflection to expose getters as map entries), such that Soy would always treat them as valid. Again, this is one of those things I'd happily add to the project if I could find the time.

          —

          Reply to this email directly or view it on GitHub.

[tomakehurst]

Cool, well as before I'm happy to merge/release anything you'd like to
contribute.

On Tuesday, 14 August 2012, zonski wrote:

I don't really want to turn off Spring's Binding/Validation stuff as I
think I can still use this in my templates (e.g. @Valid on my controller).
I'll experiment and find out, but I think the answer is more to make the
SoyViewResolver aware of Spring beans.
Funnily enough, I also just implemented a reflective ObjectToSoyMapper but
I'm using it directly in my Controller (i.e. model.addObject("myBean",
ObjectToSoyMapper.map(myBean))). It would make more sense to move this into
the ViewResolver and then, yeah, we could do some custom handling for
Spring BeanBinding. I'll put that one on the maybe-to-do list, and it will
probably be something I'm forced to look at when I start looking at
validation errors, etc.
Time is always the problem :) mine is always in fits and bursts on any
project - lets see how much I can get done before I get pulled onto
something else!

Date: Tue, 14 Aug 2012 13:13:51 -0700
From: [email protected] <javascript:_e({}, 'cvml',
'[email protected]');>
To: [email protected] <javascript:_e({},
'cvml', '[email protected]');>
CC: [email protected] <javascript:_e({}, 'cvml', '[email protected]');>
Subject: Re: [spring-closure-templates] Supporting sub-directories for soy
files (and other minor enhancements) (#1)

Regarding your last problem, this rings a bell, and I believe there is a
config attribute somewhere to stop Spring adding additional beans to the
model. I've done a bit of digging but I can't find an example of where I've
seen this. I'll let you know if I find it.

I've implemented a better solution to this problem on a commercial project
(which I couldn't open source unfortunately). This was to wrap all beans
put into the model in a Map adapter (using reflection to expose getters as
map entries), such that Soy would always treat them as valid. Again, this
is one of those things I'd happily add to the project if I could find the
time.

—

Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-7740408.