The suffer without a generic module implementation, and the cutting-and-pasting breaks my little heart. Utils.GenericFactory and such should live in resource://jsloader/utils.js and be autoloaded by the JS loader into the globals given to components. Thus it shall be.

And he looked upon it and saw it was good. And thus they spake: Go forth and commiteth thyself to implementing this. And when thou art done, and done thou art, Showeth us the fruit of thy labor. And if the fruit pleases us, Our blessings thou wilt receive.

Not critical for 0.9.

Moving to 0.9.2, because my 0.9.1 list is already too huge, and nobody's protesting in the streets to get this fixed.

Asa just told me that we shipped 0.9.2! Who knew?

->0.9.5 since we have run out of time

And an easy way to add ClassInfo would be very nice indeed.

I don't really know when I will get this done, so I'm removing the lying milestone marker.

Yes, to suffer. I've just been writing my first Javascript component, and after hours of finding bad examples, cutting, pasting, more cutting, more pasting, trial and error, I was hoping that there might be something just like this to help automate and standardize this process. But alas, there still is not. For looking at my finally operational stub of a module, I realize that I have about a hundred lines of code, not one of which is yet application specific. I might (temporarily putting aside my current unfamiliarity with some of the relevant technologies) be up for trying to write such utilities. So tell me, what would these utilities look like? Would they be patterned after the C++ macros? Would the generic factory be a factory to be used by the component, or would it be a factory to produce a whole default component? Would all the pieces be in Javascript, or would some be in mozJSComponentLoader.cpp, or might there need to be some external utility to generate a template component? What would be wonderful would be for a couple people to provide me with a sample of what a bare Javascript component using the (as yet unimplemented) utilities would look like, so I can have a better idea of what needs to be implemented.

Here's a first draft of a module using functions that would appear in utils.js. Currently, the functions are just at the top of the file; I haven't worked on having them loaded into the sandbox. But that's going to be simple, right? The sample is a working module that uses the Content Policy manager to deny loading of any images that contain "mozilla". The module itself is the 35 lines at the bottom of the file. The rest is the proposed Utils package. It is definitely a first draft, and hasn't been tested rigorously. Comments on interface and implementation would be greatly appreciated. Suggestions to scrap it and do it right also welcomed, if accompanied by a good definition of 'right'. Pointers on loading from resource://jsloader/utils.js into the sandbox wouldn't hurt.

Here's an xpt file to accompany the previous sample module, if you are inclined to try it. Save this as "nsGenericModule.xpt" and drop it off in dist/bin/components. Save the sample module as "nsGenericModule.js" and do the same. If all goes well, you'll be able to tell it is working by the lack of images on mozilla.org sites.

I had some more time to spend on this, and now have the C++ side of things working so that it loads and compiles "resource:///res/jsloader/utils", and then executes it on the Utils object of the context used by the component. It's an ugly mess right now and needs some error handling, but seems like it's all going to work. Patch to follow later this week. Again, input on interface would be appreciated.

This patch (along with the tar file to follow) should provide a Utils object to all Javascript modules. I think this is a useful addition that will make it significantly easier for people to write Javascript modules. It still includes some excessive debugging statements, and a few places marked FIXME where I could use some outside input, but otherwise seems like a working solution to me. It's only been tested lightly, and only on Phoenix under Linux. I'd appreciate if people could try this out and offer their review. Thanks!

Here are some more files necessary for the previous patch. I didn't do them as diffs because they are new, and hence not in CVS. Untar at the top mozilla/ directory. In js/src/xpconnect/loader/sample/ you will find a sample generic Javscript module.

Alex: I think you'd own this better than I, given your subscriptloader work.

shaver, we now have Components.utils.import, and XPCOMUtils.jsm. Is this adequate enough to close this bug?

XPCOMUtils.jsm is what this bug was all about, so closing.