From: paddy <pa...@pa...> - 2004-12-07 20:02:56
Attachments:
virtualmin_checkconfig_1
virtualmin_details_1
|
Jamie, Sorry this has taken me a while to get around to. Attached are two patches, but they are as yet rather rough. They attempt to implement the following on edit_domain: config option for 'check_config on page load' button for check_config features table is now 1x4, instead of 2x2 col1: feature col2: enabled? col3: configured? col4: details (if -x details-$feature.cgi) individual check_$feature_config subs in each feature-$f.pl individual details-$feature.cgi redirects The flaws are no doubt legion, but I feel I should highlight that _at least_ the following are still on my todo list: lang support: 'ui text' -> $test{'ui_text'} as appropriate feature plugins webalizer (mine is broken ?) make details-dir redirect to file manager ? (get my java working) My approach to 'configured?' is rough and ready. I started with a free-form text return rather than a specific coding, and I've yet to arrive at position on where such an interface should go. At least once I've reached for a check_$feature_config routine for a reassuring binary 'yes we can do that', even though I generally believe in 'try it and return an error if necessary'. Given the typical cost of a check_$feature_config, more could be done both in terms of checking and in terms of feedback. Also, I'm peripherally aware of html techniques that enable population of a slow rendering table after the rest of the page, but I'd need to look up the implementation, and I've no idea whether such a technique would fit in well with webmin. I would have put the 'check' button at the top or bottom of the column, if I could easily have worked out how :) With the 'details' links, I have chosen the easy route with individual cgi's and treating the relationship between site and feature as essentially one-to-one (with the exception of mail which was already there, maybe I've overlooked others ?). Nowhere is the latter hack more painfully obvious to me than in details-logrotate. Martin, I really have tried to avoid <td></td> and use <td> </td> :) Anyway, enough waffle from me. Please see attached code, feel free to tell me what you think! Regards, Paddy -- Perl 6 will give you the big knob. -- Larry Wall |
From: paddy <pa...@pa...> - 2004-12-08 12:27:06
Attachments:
delayed_table.cgi
|
On Tue, Dec 07, 2004 at 08:02:47PM +0000, I wrote: > Also, I'm peripherally aware of html techniques that > enable population of a slow rendering table after the rest of the page, > but I'd need to look up the implementation, and I've no idea whether > such a technique would fit in well with webmin. Attached is a simple demonstration program using the technique I was thinking about, which uses javascript. I indebted to jotti, at whose excellent 'online virus scan' I first noticed this technique: http://virusscan.jotti.dhs.org/ Regards, Paddy |
From: paddy <pa...@pa...> - 2004-12-10 02:08:40
|
Hi, In the bakery this morning, a lady said "I only have to see fresh cream and I blow up like a baloon". There was a strange light, a moment of quiet and the unshakeable impression that all the ladies, customers and staff alike, were sharing a moment of telepathic psychic unity. I almost expected some cheesy "choirs of angels" film music, and then it was gone. Really, I kid you not. Attached is a little number I'm calling fondant_index although the actual implementation takes place in the lib, and a by the numbers icon collection to go with it. In it's defence: language independence appeals to some users economical on space, easier to read a thousand links on a page (scary!) low in calories Nevertheless it could probably use some cleaning up. Also attached: webalizer bits. check_configured and details.cgi sketches for webalizer. I finally read the code/figured out how virtualmin does it. Random Musings: This webalizer check_configured starts to expand on the idea of a more than binary output. I have already wondered whether the dependencies of a a given service couldn't be structured so as to enable a generic implementation and rapid customisation. But that's a long way off ;) I currently have a set up where all the webalizer runs off a single daily cron job. This has the virtue of queing the jobs rather than kicking off a large number simultaneously, I'm lazily imagining the converse for the present setup without actually checking the details. In general, I can't see how it could be practical to trace all possibities when it comes to figuring out whether a job is cronned or not, perhaps some index is called for. Of course this is a general problem. Standard disclaimers: Yes, none of the code is good enough to include yet, although I hope it is worth looking at. I still have a todo list :) Although (in my walter mitty imagination!) I am an experienced programmer, my perl is at 'pigeon' level. I mostly 'monkey see, monkey do', I will certainly misguess the consequences of some logical operations, leading to straight-foward bugs, and I have no concept of what is happening under the covers, so can make only simple guesses about performance implications. Beware! Thanks once again for looking at this stuff. Regards, Paddy -- Perl 6 will give you the big knob. -- Larry Wall |
From: Jamie C. <jca...@we...> - 2004-12-12 23:42:30
|
This patch looks good too .. but let me know when you feel it is totally done, and I will review the final version for inclusion in Webmin .. - Jamie On Thu, 2004-12-09 at 18:08, paddy wrote: > Hi, > > In the bakery this morning, a lady said "I only have to see fresh cream > and I blow up like a baloon". There was a strange light, a moment of > quiet and the unshakeable impression that all the ladies, customers and > staff alike, were sharing a moment of telepathic psychic unity. I almost > expected some cheesy "choirs of angels" film music, and then it was gone. > Really, I kid you not. > > Attached is a little number I'm calling fondant_index although the actual > implementation takes place in the lib, and a by the numbers icon collection > to go with it. In it's defence: > > language independence > appeals to some users > economical on space, easier to read > a thousand links on a page (scary!) > low in calories > > Nevertheless it could probably use some cleaning up. > > Also attached: webalizer bits. check_configured and details.cgi sketches > for webalizer. I finally read the code/figured out how virtualmin does it. > > Random Musings: > > This webalizer check_configured starts to expand on the idea of a more than > binary output. I have already wondered whether the dependencies of a > a given service couldn't be structured so as to enable a generic > implementation and rapid customisation. But that's a long way off ;) > > I currently have a set up where all the webalizer runs off a single daily > cron job. This has the virtue of queing the jobs rather than kicking off > a large number simultaneously, I'm lazily imagining the converse for the > present setup without actually checking the details. > > In general, I can't see how it could be practical to trace all possibities > when it comes to figuring out whether a job is cronned or not, perhaps > some index is called for. Of course this is a general problem. > > Standard disclaimers: > > Yes, none of the code is good enough to include yet, although I hope it > is worth looking at. I still have a todo list :) > > Although (in my walter mitty imagination!) I am an experienced programmer, > my perl is at 'pigeon' level. I mostly 'monkey see, monkey do', I will > certainly misguess the consequences of some logical operations, leading > to straight-foward bugs, and I have no concept of what is happening under > the covers, so can make only simple guesses about performance implications. > Beware! > > Thanks once again for looking at this stuff. > > Regards, > Paddy |
From: Jamie C. <jca...@we...> - 2004-12-12 23:42:27
|
Hi Paddy, I finally got around to looking at your patch, and it looks good so far. One small suggestion though - perhaps it might make sense to move the code that works out what URL to redirect to into a function in the appropriate feature-*.pl files? That way there could just be a single .cgi that does the re-direction to whatever that function returns. That's really a matter of taste though .. Anyway, let me know when you think this patch is done, and I will be glad to include it in the next Virtualmin release .. - Jamie On Tue, 2004-12-07 at 12:02, paddy wrote: > Jamie, > > Sorry this has taken me a while to get around to. > > Attached are two patches, but they are as yet rather rough. > > They attempt to implement the following on edit_domain: > > config option for 'check_config on page load' > button for check_config > features table is now 1x4, instead of 2x2 > col1: feature > col2: enabled? > col3: configured? > col4: details (if -x details-$feature.cgi) > individual check_$feature_config subs in each feature-$f.pl > individual details-$feature.cgi redirects > > The flaws are no doubt legion, but I feel I should highlight > that _at least_ the following are still on my todo list: > > lang support: 'ui text' -> $test{'ui_text'} as appropriate > feature plugins > webalizer (mine is broken ?) > make details-dir redirect to file manager ? (get my java working) > > My approach to 'configured?' is rough and ready. I started with a > free-form text return rather than a specific coding, and I've yet to > arrive at position on where such an interface should go. At least once > I've reached for a check_$feature_config routine for a reassuring binary > 'yes we can do that', even though I generally believe in 'try it and > return an error if necessary'. Given the typical cost of a > check_$feature_config, more could be done both in terms of checking and > in terms of feedback. Also, I'm peripherally aware of html techniques that > enable population of a slow rendering table after the rest of the page, > but I'd need to look up the implementation, and I've no idea whether > such a technique would fit in well with webmin. I would have put the > 'check' button at the top or bottom of the column, if I could easily > have worked out how :) > > With the 'details' links, I have chosen the easy route with individual > cgi's and treating the relationship between site and feature as essentially > one-to-one (with the exception of mail which was already there, maybe I've > overlooked others ?). Nowhere is the latter hack more painfully obvious to > me than in details-logrotate. > > Martin, I really have tried to avoid <td></td> and use <td> </td> :) > > Anyway, enough waffle from me. > > Please see attached code, feel free to tell me what you think! > > Regards, > Paddy |