New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rhino based compilation of Coffeescript for Coffeescript filter #6

Merged
merged 1 commit into from Sep 9, 2011

Conversation

Projects
None yet
2 participants
@daggerrz
Contributor

daggerrz commented Sep 9, 2011

Quick win for server based compilation (based on https://github.com/daggerrz/scala-coffee), but I have a few open questions that need to be answered before merging:

  • How to get access to line number information to give user a more informative error message on Coffee compilation error
  • Is there any reason to keep the browser based compilation at all (even when in dev-mode)?
  • How to handle the Rhino dep. Move to separate module?
@daggerrz

This comment has been minimized.

Show comment
Hide comment
@daggerrz

daggerrz Sep 9, 2011

Owner

Open questions:

  • How to get access to line number information to give user a more informative error message on Coffee compilation error
  • Is there any reason to keep the browser based compilation at all (even when in dev-mode)?
  • How to handle the Rhino dep. Move to separate module?
Owner

daggerrz commented on 978df58 Sep 9, 2011

Open questions:

  • How to get access to line number information to give user a more informative error message on Coffee compilation error
  • Is there any reason to keep the browser based compilation at all (even when in dev-mode)?
  • How to handle the Rhino dep. Move to separate module?

jstrachan added a commit that referenced this pull request Sep 9, 2011

Merge pull request #6 from daggerrz/master
Rhino based compilation of Coffeescript for Coffeescript filter

@jstrachan jstrachan merged commit 1c73f37 into scalate:master Sep 9, 2011

@jstrachan

This comment has been minimized.

Show comment
Hide comment
@jstrachan

jstrachan Sep 9, 2011

Contributor

AWESOME stuff, huge thanks! Will ponder the line number. Optional
dependency sounds fine (maybe we should use the old way if no rhino
found?)

On 9 September 2011 04:30, Dag Liodden
reply@reply.github.com
wrote:

Quick win for server based compilation (based on https://github.com/daggerrz/scala-coffee), but I have a few open questions that need to be answered before merging:

  • How to get access to line number information to give user a more informative error message on Coffee compilation error
  • Is there any reason to keep the browser based compilation at all (even when in dev-mode)?
  • How to handle the Rhino dep. Move to separate module?

You can merge this Pull Request by running:

 git pull https://github.com/daggerrz/scalate master

Or you can view, comment on it, or merge it online at:

 #6

-- Commit Summary --

  • Coffeescript compilation support for coffeescript filter

-- File Changes --

M scalate-core/pom.xml (8)
A scalate-core/src/main/resources/org/fusesource/scalate/filter/coffee-script.js (8)
M scalate-core/src/main/scala/org/fusesource/scalate/filter/CoffeeScriptFilter.scala (79)
A scalate-core/src/test/resources/org/fusesource/scalate/scaml/coffee.scaml (2)
A scalate-core/src/test/scala/org/fusesource/scalate/filter/CoffeeScriptFilterTest.scala (18)

-- Patch Links --

 https://github.com/scalate/scalate/pull/6.patch
 https://github.com/scalate/scalate/pull/6.diff

Reply to this email directly or view it on GitHub:
#6

James

FuseSource
Email: james@fusesource.com
Web: http://fusesource.com
Twitter: jstrachan
Blog: http://macstrac.blogspot.com/

Open Source Integration

Contributor

jstrachan commented Sep 9, 2011

AWESOME stuff, huge thanks! Will ponder the line number. Optional
dependency sounds fine (maybe we should use the old way if no rhino
found?)

On 9 September 2011 04:30, Dag Liodden
reply@reply.github.com
wrote:

Quick win for server based compilation (based on https://github.com/daggerrz/scala-coffee), but I have a few open questions that need to be answered before merging:

  • How to get access to line number information to give user a more informative error message on Coffee compilation error
  • Is there any reason to keep the browser based compilation at all (even when in dev-mode)?
  • How to handle the Rhino dep. Move to separate module?

You can merge this Pull Request by running:

 git pull https://github.com/daggerrz/scalate master

Or you can view, comment on it, or merge it online at:

 #6

-- Commit Summary --

  • Coffeescript compilation support for coffeescript filter

-- File Changes --

M scalate-core/pom.xml (8)
A scalate-core/src/main/resources/org/fusesource/scalate/filter/coffee-script.js (8)
M scalate-core/src/main/scala/org/fusesource/scalate/filter/CoffeeScriptFilter.scala (79)
A scalate-core/src/test/resources/org/fusesource/scalate/scaml/coffee.scaml (2)
A scalate-core/src/test/scala/org/fusesource/scalate/filter/CoffeeScriptFilterTest.scala (18)

-- Patch Links --

 https://github.com/scalate/scalate/pull/6.patch
 https://github.com/scalate/scalate/pull/6.diff

Reply to this email directly or view it on GitHub:
#6

James

FuseSource
Email: james@fusesource.com
Web: http://fusesource.com
Twitter: jstrachan
Blog: http://macstrac.blogspot.com/

Open Source Integration

@jstrachan

This comment has been minimized.

Show comment
Hide comment
@jstrachan

jstrachan Sep 9, 2011

Contributor

An optional dependency on rhino sounds fine to me; added an enable/disable flag too. Still pondering the line number issue...

Contributor

jstrachan commented Sep 9, 2011

An optional dependency on rhino sounds fine to me; added an enable/disable flag too. Still pondering the line number issue...

@daggerrz

This comment has been minimized.

Show comment
Hide comment
@daggerrz

daggerrz Sep 9, 2011

Contributor

Sounds good, most will probably opt to use the compiler once it's there and for those who don't want the extra dep, a flag should solve their problems. Line numbers would be really useful, but it looks like that will require some refactoring of the Scalate pipeline. I'm not familiar enough with the source to make any suggestions, though...

Contributor

daggerrz commented Sep 9, 2011

Sounds good, most will probably opt to use the compiler once it's there and for those who don't want the extra dep, a flag should solve their problems. Line numbers would be really useful, but it looks like that will require some refactoring of the Scalate pipeline. I'm not familiar enough with the source to make any suggestions, though...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment