I think I'd prefer to keep the number of bundled modules / scripts in Webmin low for now.. Unless there end up being many many modules using them.

Perhaps a better solution would be for this .js files to be packaged in a Perl module, that can be installed on systems running your Webmin module. That said, the overhead of a few .js files in minimal.

That's okay, I came up with another solution - I made a Scriptaculous module. :)

I'd post it, but can't find the instructions for bundling a .wbm. :)

nm, found it. :)

http://www.numbski.com/downloads/scriptaculous.wbm.gz

Very quick and dirty. Basically it installs, then you will want to do a foreign_require to pull it in at the lib file, and at the top of your .cgi file, do a foreign_call to scriptaculous-lib for scriptaculous_headers, store it to a scalar, and put it into &header in the 8th parameter slot.

Probably add a few more functionas such as only having certain libraries load, but hey - this way all modules can share it. All I have to do then is require that module from my other modules.

Yes, that's a good solution too ..
And since this module exists only to provide a library to others, you can add the hidden=1 line to it's module.info file to prevent it appearing in the module lists..

I'd actually done that originally, but had issues (unrelated). If you look in module.info, you'll see I have hidden=0. Can be changed though. I'm going to play with it for a few days, see if I wind up needing or using other functions, and I'll toss it out for general consumption then.

In the meantime, I made pretty good progress on the Apache Cluster module today. Going to take a break from it this weekend and see if I can't wrap up a semi-functional version on monday.

I just thought I'd add to this thread that we probably will be integrating some sort of JavaScript utility and widget library in the standard Webmin bundle at some point in the future (and the existing JavaScript functions will get some kind of overhaul or be stripped out, as they aren't in their own namespace and just aren't making use of modern best-practices). We're using extjs in our new AJAX-y theme, and it has quite a lot of good widgets and functions. We're also using yui for some of its utility functions, but that can be abstracted away (extjs for example can select between jquery, prototype or yui for its utility function library).

Back to work on this again today. :)

I did wind up adding a few functions to the Scriptaculous module, generate_draggable_icon, generate_editable_text, and generate_drop_receiver. Each does what it suggest. Each one triggered by

&foreign_call("scriptaculous", (function name), %options)

Each one returns a scalar with HTML in it, all the user has to do is print the scalar. :) Should make generating Ajax elements dead simple. I know I want to implement generate_sortable_list at very least still. I can't think of any other interactive elements I would personally use, but hey. :)

Nice ..
By the way, you can also call functions from other modules with more standard Perl syntax of :

scriptalicious::functionname($args);

That's helpful to know, thanks! :)

Hey, stupid question.

Does ReadParse() not know how to deal with multiple arguments with the same name? I've tried this using a select multiple, and simply check boxes with name=nodes. I need to be able to submit multiple nodes at the same time (node id's to be exact), and from what I'm reading, the form submission should go like this:

remote_api.cgi?function=add_replicas&nodes=id1id2id3

This isn't happening though. Whatever hte last value for nodes is overwrites the previous, so I get the very last one every time. I've tried doing @nodes = split(//,$in{nodes}), which I'm certain I've been able to do before, but for whatever reason it doesn't work. The value of $in{nodes} is a string and that string in the above example would be id3, rather than id1id2id3. I could always go outside the API and parse STDIN myself, but I'd prefer to use webmin's API and not reinvent the wheel.

Any idea what I might be doing wrong?