These are chat archives for canjs/canjs

11th
Dec 2015
Matthew Phillips
@matthewp
Dec 11 2015 03:54
@patrickclancy sure, what makes you concerned about that?
Anthony Stansbridge
@Stansbridge
Dec 11 2015 11:27
Hey @alexisabril We've got a very large JMVC 3.2.4 project. We're looking for a clean way to inject the view name being rendered inside each view as a HTML comment. We want a method that allows us to use this injection when developing but removes the code (and overhead) from our releases. We've tried a lot of things and we have some very experienced JMVC 3.2.4 devs on the project, we're struggling to get something working. We've tried patching against the internal 'compile' function of the ejs template code, checking if the navigator.userAgent header matches Rhino (terrible hack, we know :)) to distinguish between development/builds. The problem with this is when you compile an EJS template that does not render HTML but instead renders attributes for a form (for example)... basically it doesn't work where we use EJS as a string interpolation method. Another issue we had was the //!steal ignore comments do not execute against some specific internal files.
We were hoping that we could locate some absolute JMVC 3.2.4 geniuses to poke us in the right direction, this addition would be massively helpful :-)
The nice thing about monkey patching the ejs compile method is the build process compiles the templates as part of the build... thus performing all overhead inside Rhino... we don't mind what hacks go on then :-)
Anthony Stansbridge
@Stansbridge
Dec 11 2015 11:33
To expand on why it doesn't work when using EJS to do string interpolation... the injection of a HTML comment would break things: <input <!-- oops a comment --> /> :-)
Obviously we could attempt to detect whether the template being compiled is HTML or something else... we've had a good laugh at crazy ideas, but haven't figured out anything viable.
Matthew Phillips
@matthewp
Dec 11 2015 11:51
@dylanrtt @patrickclancy It's true that %root isn't needed for it's original purpose any more (asynchronous rendering for server-side) but I don't see any reason to remove it.