Hi Tony,
The ReadParse function has a pretty silly way of handling multiple parameters with the same name - it just puts them into a single value in the %in hash, separated by null bytes (). So if you had a form like :

<input type=checkbox name=foo value=1> One
<input type=checkbox name=foo value=2> Two

You could get the selected checkbox values with :

&ReadParse();
@checked = split(//, $in{'foo'});

If you look above, that's precisely what I'm doing, but I only get the last passed value. I'll go ahead and work around this for now and make a note to come back to it later.

Thanks!

Update - it's not ReadParse(), as my grabForm() routine (that I used to use in old cgi scripts) has the same problem. The issue appears to be with HTML::Prototype's use of serialize. It tries to use the convention form.serialize(This), which is a deprecated convention. Ajax doesn't pay attention to form id's and values on submission unless you serialize them first. The way that HTML::Prototype does it is only getting the last value.

http://prototypejs.org/api/form/serialize

Not that it matters to you per se, but I figure if it helps someone else in the future, might as well put it here for searchability. ;)

I am about ready to rip my hair out now. :P

Fixed the form input issue. Values are getting passed to what I have named remote_api.cgi. This doesn't return a full html document, rather just bare http headers, and some text that updates the page in real time. This works as well.

The problem is something stupidly simple that I can't seem to get working.

I make a sub named add_nodes_as_replicas, which takes an array as an argument. I thought I had this working when I did it on the command line, but it has since stopped.

I pass an array with node id's, and it is supposed to either return 0 for success, or a string with an error message. Again, dead simple.

Well...not when I'm involved apparently. :P First thing I do is run a test to make sure I got parameters to begin with, so I did:

if(! @_){
return($text{'no_nodes_for_addition'});
}
else{

It passes that condition and goes into the main routine.

my @nodes_for_addition = @{ $_[[0]] };

if(! @nodes_for_addition){
return ("Some useful debugging thing here");

This is where I get tripped up. @nodes_for_addition isn't getting populated, and I'm afraid it is because of the way I'm passing that array, but I'm not sure. I'm calling it using this syntax: add_nodes_as_replicas(@nodes);

You have to escape the at sign in order to get it to pass at all. If I iterate through @_, I can confirm that $_[[0]] did get populated, and if I attempt to print $_[[0]], I get this:

ARRAY(0x804dd78)

So it is populated with an array (or at least an array reference?), so then I thought I'd get smart and use @{ $_[[0]] }, which again makes sense, but that comes back either undef or null (can't tell which). Logic tells me that it should print out a space-separated list of the node id's. I also tried to get smart and do scalar(@{ $_[[0]]}), hoping it would give me a count of the number of nodes passed, again, it does not. If I go back to the original routing (prior to passing the array to add_nodes_as_replicas) and print @nodes, I get a space separated list, and scalar(@nodes) does indeed give me a count of the number of id's in the array.

Which brings me to my conundrum - am I using poor syntax when passing the array as an argument to add_nodes_as_replicas(@array), or am I trying to reference it incorrectly? Perhaps I should be using a pointer in there? I've even tried @{ $_[[0]] }->[[0]] in an attempt to get at the first element, no luck. :(

Any ideas?

I've figured this much out - without the , I'm passing the array itself. With the backslash, I'm passing an array reference.

In either case, the actual values within the array aren't getting through. If I pass @nodes, attempting to print is null or undef. If I pass @nodes, it's populated with an array reference. Attempting to dereference it gets me null or undefined @{$_[[0]]).

So...yeah. What on earth. I'm passing hashes as params all over the place. I have no idea what I'm doing that is giving me such headaches using an array.

Could you post the function and the call to it? It is probably a simple mismatch between the format passed and expected ..

If you want to pass an array, you can use code like :

my_function(@array);

sub my_function
{
my ($arrayref) = @_;
foreach my $e (@$arrayref) {
print "array element $en";
}
}

I will try to in the morning. In the interim, you might be amused to know that my form submission problems were theme-related.

I'm using theme-stressfree, and that calls prototype.js on it's own, plus I call my prototype.js. His is older than mine, and there's no namespace separation in an html document. :P His javascript was breaking mine basically. As soon as I went back to the "Old Webmin" theme, my code started working.

Short term I'm going to hack theme-stressfree a bit more to call my libs, but long-term the idea is getting into my head that maybe a scriptaculous module isn't the right answer so much as an "ajax-toolkit" or "webmin-widgets" one. That way all old stuff continues working, but people could use newer widgets too.

Dunno. Perhaps theme-stressfree is the only one that makes prototype or ajax calls, and I'm only having issues by asking too much. :)

Alrighty. A simple change to theme.pl in the StreeFree theme has me fixed up there. I simply commented out the print statements for prototype.js, effects.js, and controls.js, and instead did my scriptaculous::scriptaculous_headers call. All is well again. :)

I noticed he uses nifty.js as wel, which is the Nifty Corners Cube library.

http://www.html.it/articoli/niftycube/index.html

So if I'm seeing this right, overall we have 3 libraries that get used around here...Prototype/Scriptaculous, Nifty Corners Cube, and yui (I've never looked at this...).

I'm going to focus on my apache-clustering module for now, adding functions to the scriptaculous module as needed, then I'll come back and try to sort out the js functions conundrum. Probably just bundling these all into a widgets module is the best way to go, and then separate function calls, like scriptaculous_headers(), yui_headers(), and nifty_headers(). The catch to that of course is that various widgets will require different headers, so the function docs would have to specify, ie if you wanted to generate_editable_text(), you must have included scriptaculous_headers() in your header statement someplace.

Okay, back to making things work instead of making things pretty. :)

Huh, I just noticed a pretty serious rendering bug in the apache module while using the StressFree theme. The icon table at top doesn't get rendered. The first thing that gets rendered are the words "Existing Virtual Hosts". I've tested in both Firefox and Safari. Looks to be a styelsheet problem, but I haven't been able to nail it down yet.

More of an FYI than anything. I guess the one to make aware is the author, and not you guys. ;)

Ah well...gives me an excuse to let you know that I've made some pretty good progress here. I wound up tooling my own config file format in XML using XML::Twig, which will allow me to store far more information per node. I'm calling nodes in the cluster replicas as to tell them apart from cluster nodes that are not a part of the apache farm.

Anyway, the replias get stored in $module_config_directory/config.xml. Right now the only keys that are defined are config (the root), and server with subkeys id and comment. I know I'm going to add a few more subkeys under config with global options, and probably a few more subkeys under server with per-system options.

I'm doing everything I can to avoid page refreshes within the module, as tasks such as node status updates would require a page refresh per-node, and that's no good. :) For the moment I'm tweaking the add_nodes_as_replicas function so that the replica list gets updated in real time (almost done), and then I need to get the node list to update at the same time so that whatever node I just added is no longer in the list of available nodes, then work out hte reverse, so that when I remove a replica, it updates the list of available nodes, and removes the replica from the replicas list (whee....).

Anyway, these are all just UI rendering issues. I'm more or less done with the read config/write config/update config issues. Once I finish tweaking up the UI (hopefully today?) then I'll start hash in the functions that actually push out updates to the replica servers. The last step after that is to allow the user to optionally define a balancer, so that when new virtual hosts are assigned with dedicated IP's, the module can optionally go out and update whatever balancer mechanism is being used.

Work work work. I haven't done this much coding in a very long time. My fingertips are starting to blister. (I wish I were kidding...)

Just a quick update. I've finished work on the basic UI the module will be using. I think I'm going to make a prereq of rsync on the boxes participating in the cluster. No reason to reinvent the wheel when a superior tool is available, and for free.

So the next order of operations is to trigger the creation of a serial file that goes into apache's config directory side-by-side with httpd.conf (or equivalent). The file will contain a simple timestamp, and perhaps md5's of all relavent config files. I then need to check Virtualmin to see how it handles updating apache, and get it to trigger a remote command call on each cluster box that rsync's the config from the master. The master will be running an rsync share that is locked down to the IP addresses of the cluster nodes (although I would strongly suggest firewalling it, or better, running it on a private interface). A check will run to make sure the serial number is current, and that md5's match up. Presuming all is well, it will then trigger whatever that node's "apply" command is.

This is all still pretty rough around the edges. Hopefully in the next week or so it will mature enough to make a testing release. Amongst the known problems are that it is not 100% localized (lots of plain english strings when I was lazy and didn't put it in the lang/en file and make a call to that instead), lots and lots of commented debug code that I haven't removed for fear of needing it again, a couple of newly created "webmin widgets" (what I think I'll finally name that Scriptaculous module) that are in the base code rather than being out in the the separate module where it belongs, and the fact that I haven't checked as to have to make sure the user has all required perl modules installed and tell them about it (HTML::Prototype and XML::Twigs at the moment).

I'm particularly proud of the errorConsole widget I made. :) It draws a pretty display box on screen, and you can populate it with text on the fly using the JavaScript call errorConsole('your text here); - it puts it into a monotype font, automatically adds line breaks and scrolls the text like a console window. I've thought about adding some color adjustment options and stuff, but for now it works, and looks pretty cool. The only issue I have with it is that in Safari the style pre-wrap isn't recognized, and ignores all line breaks and newlines, so you can send n or[br/> until the cows come home, it still won't break the line. Really weird.

I guess that's it for now. As I said, I'm hoping to have a functional pre-alpha quality module up for testing sometime this next week. If I do as I should, there will actually be two modules getting installed, webmin-widgets, and apache-cluster.