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).
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
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.
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.
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.
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. 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.
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.
I agree that the header function should use format parameters instead of $_[[X]] … I just haven’t gotten around to fixing it yet
If you prefer a hash-based function call, I’d suggest writing your own wrapper around header() instead, so as not to break existing modules and themes.
Alright. I feel really dumb, but this project isn’t dead. I got dragged off into the MySQL balancer mess, and I almost have that fixed up, then I’m going to have to make a trip to Montreal. I’m working on this in what spare time I have. Just FYI.
Wow, I guess it’s been a while since I’ve done this:
manager# perl index.cgi
Undefined subroutine &main::init_config called at ./apache-cluster.pl line 5.
Compilation failed in require at index.cgi line 6.
manager# head index.cgi
#!/usr/bin/perl
index.cgi
Main configuration page for the Apache Clustering Module.
It results in a nice draggable tile. The not-so-good - probably shouldn’t go bundling a separate copy of prototype and scriptaculous with modules. I know I’m going to be writing at least one other module (Asterisk Provisioning) after this one, and if everyone were doing this, we’d have dozens of copies of the same .js files floating around. Any chance you might consider bundling a copy into Webmin for calling in? If not, it’s not big deal. This works fine for me right now.
His javascript was breaking mine basically. As soon as I went back to the “Old Webmin” theme, my code started working.