Optimizer not working with Rhino about require-css

[guybedford]

Amazing, thanks for this - have commited the change.

Yes, any help on the saveFile function would be greatly appreciated. It should be standard Java, I just wasn't sure about it and don't have a testing environment set up myself.

If you have any ideas for compression support in Rhino, let me know. Basically I'm calling this library currently - https://github.com/css/csso. Not sure how to call that within Rhino.

[guybedford]

To clarify, the only thing needed to get the separateCSS output to work in Rhino, is to finish writing the 'saveFile' function. I've commented the place where it needs work (with a cry for help :P).

[mparisot]

and here is the saveFile function :

function saveFile(path, data) {
        if (typeof process !== "undefined" && process.versions && !!process.versions.node && require.nodeRequire) {
            var fs = require.nodeRequire('fs');
            fs.writeFileSync(path, data, 'utf8');
        }
        else {
            var encoding = "utf-8",
                content = new java.lang.String(data),
                output = new java.io.BufferedWriter(new java.io.OutputStreamWriter(new java.io.FileOutputStream(path), encoding));

            try {
                output.write(0xffef);
                output.write(content,0,content.length());
                output.flush();
            }
            finally {
                output.close();
            }
        }
    }

A bit strange to write java mixed in javascript but that works for me and should be the java equivalent of the writeFileSync of node.js :)

I didn't touch the node.js part of the method ;)

For CSSO it would be a lot trickier because it seems it rely a lot on node.js module management and honestly I don't think it's worth it for the moment as the basic CSS compression is enough for me.

Just check it still works fine with node because I don't have one on my side.

You could probably regroup the "utf-8" string to be common for both java and node or even make it a configuration option since it's used at several places in the code but I let you do that! :p

[guybedford]

Amazing, thanks so much for this!!

I ran the tests my side and everything seems to still be working fine so have committed that in.

Yes csso will be a little more tricky as you say - but the basic optimization should be enough.

One question - in the loadFile, there is a check against 0xfeff, while in the writeFile there is a write of 0xffef. Are these supposed to be different values?

[mparisot]

I just kept that from your code, to be honnest I had no idea what they are there for :p

So now I checked : http://en.wikipedia.org/wiki/Byte_order_mark

And it should be FEFF.

It seems java doesn't use it and it's optional so you can just delete that line in the writeFile function.

But you need to let it in the load because if it's present java won't skip it, so you have to do it manually.

And yeah you can curse java for it's "great" file API... they redid it in java7 but most companies are still in older versions so I made my code as compliant as possible ;)

[guybedford]

Ok I've taken it out of the write function. Makes sense if it's optional. Your code looks a lot simpler than the load function I must say though.

[mparisot]

It's easier to write because you know the size of what you will write.

When you read you have to read each line until you are done and append it to the rest of the file. The added complexity is there that's all.

Then you have the BOM problem and the fact that they preserve the lines and the java factor which make it 10 lines bigger just because it's java (I love this language but for this kind of things it's really a pain when you don't have external libs)