Make JS Preprocessing Pluggable

Here is my first pass at a pluggable JavaScript preprocessor.

Updated the interface name to JSPreprocessingInterface for consistency and fixed some comments.

Looks pretty good to me. Some formatting issues:

need to indent two spaces under the @s. That goes for just about all of the PHPDocs.

I know these bits are just getting moved but that's no reason not to improve them:

I'd say "Ensure there's a js directory with in the files directory that it is writable."

I think you should also make it writable:

Thanks for the feedback, drewish. Updated.

The last submitted patch failed testing.

Previous patch still applies with no issues for me.

Any chance you can name preprocessing to something else? The theme system has kinda taken over that name.

@moshe weitzman - I'm open to a name change. Drupal 6 already uses preprocess when refering to JavaScript so it would be a name change from an existing convention. Though, this topic is out of the scope of this patch which is just to take an existing system (with an existing name) and make it pluggable. It's primarily a re-factoring of code.

Stuck up a note about this issue in the JavaScript Aggregator module: #356596: Port to Drupal 7.

Would be nice to have a test case. I'll see what I can do....

Had to make the preprocessor able to lazy load classes from different files. This meant moving JSPreprocessingInterface to common.inc, and changing "preprocess_js_system" to:

....When the preprocessor is loaded, it will check "file" and include that file before creating the interface.

As for the tests, I got pretty far, but couldn't get it to work all the time. Help appreciated.

....... Forgot the patch.

@rob - thats D6 style code. We no longer have to specify files, with the code registry.

Why are we telling it what file to load? The registry takes care of loading files for classes and interfaces. If it's in the includes folder it just finds it. If it's a module you define what module files to scan. See http://drupal.org/node/224333#registry and http://api.drupal.org/api/group/registry/7.

Fixed the tests, but am having troubles with the registry. Assistance would be nice.

Ahhh, had to add common.test to the registry.

I updated the test to remember the configured class for the JS Preprocessing and restore it after the test.

2 Questions:

• Is it appropriate for tests/common.test to be listed in simpletest.info?
• The layout of how we have an interface mixed between functions, is that appropriate? Or, should it be at the start or end of the file? Maybe someplace else?

Is it appropriate for tests/common.test to be listed in simpletest.info?

I'd love for it to be referenced somehow else, but can't think of anything since it's running on a different process and the class isn't loaded. Any other ideas would be awesome.

The layout of how we have an interface mixed between functions, is that appropriate? Or, should it be at the start or end of the file? Maybe someplace else?

I don't think it really matters, but we could move it to a different class if that's prefered.

The attached patch moves including common.test to a javascript_test module in the tests folder. The javascript_test.info file includes the module. The javascript_test.module file is a dummy file. If we change core to not require module files this can go away. The setup function for the javascript tests enables this module.

This is looking pretty much RTBC, but Crell just posted #363787: Plugins: Swappable subsystems for core, so I think we should see how it grows...

Great work! The same should be applied to CSS preprocessing.

Subscribing.

nice, subscribing

I don't think the plugins/handlers system will make it into D7. So, here is an update to the previous series of patches that store the class in a variable.

This is the overall layout of the functionality but the tests could use some work.

The last submitted patch failed testing.

Rerolled the patch. Didn't test it, just a straight re-roll.

The last submitted patch failed testing.

Sub