Using Javascript functions in lessCss processing

[GoogleCodeExporter]

As part of the less files I'm looking to process there is a reference to a 
Javascript function:

.contrast-colour(@base-colour) {
    color: color(`getContrastColour('@{base-colour}', 'AAA')`);
}

When processed this reports that it cannot find the function.

Hopefully there is a way to make the function available for use whilst 
pre-processing.

This is using version 1.7.0 of the wro4j maven plugin, on a windows box if it 
makes any difference.

Thanks,

Matt

Original issue reported on code.google.com by harrison...@gmail.com on 1 Sep 2013 at 10:07

[GoogleCodeExporter]

Until this feature is available, have you considered using server-side 
interpolation of  those functions?

Original comment by alex.obj...@gmail.com on 1 Sep 2013 at 10:12

• Changed state: Accepted
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Happy to have a look at it, but not sure what server-side interpolation is in 
this context.  Could you point me to something that explains it?

Thanks,

Matt

Original comment by harrison...@gmail.com on 1 Sep 2013 at 11:22

[GoogleCodeExporter]

There is a processor called PlaceholderProcessor which performs a basic 
server-side interpolation: 
https://code.google.com/p/wro4j/wiki/PlaceholderProcessor

Though isn't suitable as it is for your use-case, you can use it as an example 
which can be used as a starting point. 

This processor can be used as a post processor or pre processor applied after 
lessCss, when the variable will already be replaced by less. 

Let me know if you have any questions.

Original comment by alex.obj...@gmail.com on 2 Sep 2013 at 7:19

[GoogleCodeExporter]

I've been having a little look at this - it looks a little bit awkward to get 
the additionally referenced files in at the point its needed (which I believe 
is in LessCss.java, is that right?).

I did get it working by adding a new property into the property file, and then 
pulling that through to the context, and then looking it up when building the 
RhinoScriptBuilder, i.e. something like (and yes it is very much hacked in - at 
the moment you can just add one file):

private RhinoScriptBuilder initScriptBuilder() {
    try {
      RhinoScriptBuilder builder = null;
      if (scope == null) {
        final InputStream initStream = LessCss.class.getResourceAsStream(SCRIPT_INIT);
        builder = RhinoScriptBuilder.newClientSideAwareChain().evaluateChain(initStream, SCRIPT_INIT).evaluateChain(
            getScriptAsStream(), DEFAULT_LESS_JS);
        if (StringUtils.isNotEmpty(Context.get().getConfig().getLessAdditionalContextFiles())) {
            InputStream test = new FileInputStream(Context.get().getConfig().getLessAdditionalContextFiles());
            builder.evaluateChain(test, "colour_utils.js");
        }
        scope = builder.getScope();
      } else {
        builder = RhinoScriptBuilder.newChain(scope);
      }
      return builder;
    } catch (final IOException ex) {
      throw new IllegalStateException("Failed reading javascript less.js", ex);
    } catch (final Exception e) {
      LOG.error("Processing error:" + e.getMessage(), e);
      throw new WroRuntimeException("Processing error", e);
    }
  }

But does this approach seem like it might be a way to go?  Or did you have a 
better idea/plan?

Thanks,

Matt

Original comment by harrison...@gmail.com on 17 Sep 2013 at 3:36

[GoogleCodeExporter]

Thanks for your input.

Making it possible to evaluate javascript inside less would be a great 
addition. But I would not like to pollute the configuration object with various 
processor related settings. Context.get().getConfig() should be responsible for 
holding generic configurations. The best way to configure processor, is to 
create a custom one. This is very easy to do, check out this example: 
https://github.com/wro4j/wro4j-examples/tree/master/custom-processors 

Original comment by alex.obj...@gmail.com on 17 Sep 2013 at 6:56

[GoogleCodeExporter]

Ok, sounds good.  I was just working through creating a custom processor, and 
to do the import of the javascript I'm going to need to know the path to import 
from (which will be different from one machine tothe next).  My thought was to 
make the path relative to the 'contextFolder', which would then be ok I think.

I see this gets put into the StandaloneContext, but then is it feasible to 
reference this from a processor?

Thanks,

Matt

Original comment by harrison...@gmail.com on 18 Sep 2013 at 1:55

[GoogleCodeExporter]

You can get those from ReadOnlyContext which is injected in each processor 
(There are also other objects which can be injected, but this is out of the 
scope now). Just add a field and annotate it like this:

@Inject
private ReadOnlyContext context;

See example of how it is used in CssUrlRewritingProcessor: 
https://github.com/alexo/wro4j/blob/v1.7.0/wro4j-core/src/main/java/ro/isdc/wro/
model/resource/processor/impl/css/CssUrlRewritingProcessor.java

Original comment by alex.obj...@gmail.com on 18 Sep 2013 at 6:59

[GoogleCodeExporter]

Hi,

I did get this working for us.  What I did in the end was to extend the 
RhinoLessProcessor, and got it to scan the less file for a special comment (for 
example: '//{{wro4jJsInclude:/js/colour_utils.js}}'  )  which then contained 
the path to the js file to include when processing.

Do you think this is a good way to go?  Or is there a better option?  If this 
sounds ok should I create a pull request?

Thanks,

Matt

Original comment by harrison...@gmail.com on 23 Oct 2013 at 11:05

[GoogleCodeExporter]

Yes, please. I'm not yet sure how this can be implemented in a generic way,
but what I can do at least, is provide your contribution as an example for
similar feature requests.

Original comment by alex.obj...@gmail.com on 24 Oct 2013 at 6:14

[GoogleCodeExporter]

Hi,

Finally got the code up:

https://github.com/mattharr/wro4j-rhinoLessWithJsProcessor

Hopefully it will be of use to others.  If there are any questions/comments 
please let me know.

Thanks for all your hard work making this tool.

Cheers,

Matt

Original comment by harrison...@gmail.com on 18 Nov 2013 at 10:26