Thanks for the suggestions Bertrand/Lucas. I like the idea of
decoupling the cache from the compiler implementation. I've abstracted
out the cache and compiler interface to make it plugable to other web
resource types. Also beefed up the CoffeeScript unit tests. I've
created a JIRA to track any additional community feedback:
https://issues.apache.org/jira/browse/SLING-2805.
- Bob
On 3/26/2013 4:54 AM, Bertrand Delacretaz wrote:
Hi Bob,
On Tue, Mar 26, 2013 at 5:03 AM, Bob Paulin <[email protected]> wrote:
...Sling supports numerous server side scripting languages
for working with JCR but I'm curious if Sling might ever be intended to
support front end scripting languages. Projects such as wro4j
(http://alexo.github.com/wro4j) support these things but don't have the
convenience of the JCR to store compiled resources....
I like the idea, and your CoffeeScript example demonstrates it very nicely.
Having such tings in our /contrib source code folder would be great
IMO, as long as each module has meaningful automated tests they should
be easy to maintain.
There's a set of common logic and requirements for this server-side
compiling of client-side code, at least on the caching side, and that
can probably be generalized.
-Bertrand
