Re: [Ganglia-developers] Web interface enhancements patch.
On Mon, Aug 11, 2008 at 05:26:47PM -0400, Jason A. Smith wrote: There are two basic ways to navigate around the ganglia website, one way is via explicit A HREF=URL links. this is the one I'd test and which is currently inconsistent leading to some parameters getting lost while going back and forth between links just because some links are missing some of the variables. The other way, is to change one of the form values, for example, on the cluster view, you can select a new metric to view. When the form selection is changed, this executes an immediate OnChange script, which is always ganglia_form.submit();. Simply waiting the default_refresh interval will also trigger a form submit. Note, the forms in ganglia always begin in the header.php/tpl and always have the same structure: FORM ACTION=./ METHOD=GET NAME=ganglia_form I really don't see the objection to adding the hidden values, since this is the easiest, least obtrusive and best way to do this. would this work also when doing the navigation through the first method (clicking through already defined HREF)? Would you really want to make a context sensitive ACTION URL, adding the missing variables explicitly to the different view pages? no if I can avoid it, but that has been the tendency so far, so for example from cluster view to host view the hc parameter is being passed (even if it makes no sense in host view) so that it can just be passed back. if you instead go from the regular cluster view to physical view and back then hc is lost (even if it would had made sense to pass that one around in that case). What exactly is the advantage of doing it this way? This is basically the same thing that happens with hidden form values, automatically added by the browser. Since this is a GET method, the real form variables along with the hidden values are all formed into one long GET string by the web browser and submitted to the server. What exactly is the objection to using hidden form values here? I really don't understand it. bear with me here, since I most likely don't know the PHP code as well as you do and it seems from what you explained above I didn't understood this part of your patch at all (which is also part of the reason why it would had been nicer if I would have gotten instead little self contained patches with clear objectives instead). are you saying then that the reason why you had mc both in the GET URL and as a hidden form was to cover for both possible types of navigation? why then the list of hidden forms is different for each context while the URL is not? why we are leaving the possibility open for having the parameter twice in the GET URL for some links that already include them and why wouldn't be better to pass at least some of those values only once by using a cookie instead for example? Carlo - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] Web interface enhancements patch.
On Sat, 2008-08-09 at 06:34 -0500, Carlo Marcelo Arenas Belon wrote: On Mon, Aug 04, 2008 at 04:06:07PM -0400, Jason A. Smith wrote: On Mon, 2008-07-21 at 03:07 -0500, Carlo Marcelo Arenas Belon wrote: On Fri, Jul 18, 2008 at 07:33:23PM -0400, Jason A. Smith wrote: This patch takes the max_graphs option from the conf.php file and makes it configurable on the web interface. Not sure if that is the right thing to do, as it would seem that a user configurable max_graphs would make more sense integrated with an already available user configurable show_hosts. Would a separate option that allowed the user to select up to what the admin set as max_graphs be a good idea then? So one option so the admin can set a max for their ganglia server, and another for the user to specify how many they would like to see while in the cluster view. yes, and probably better if that option is overloaded in the current implementation for show_hosts, so that the number of hosts to show can be selected (default to -1 to mean there is no limit). I will work on a patch for this. - All of these values are now saved while navigating through the web interface via params in the URLs and hidden form values. Not sure if a good idea, as using hidden form values doesn't allow for URLs that are completely representative of the parameters needed to build the page and therefore will prevent people sending around ganglia URLs that are meaningful. Agree that the URL is getting polluted and this could be a way to solve that problem, but as you point out implicitly in your patch, our current handling of GET variables is incomplete, and adding yet another parameter passing mechanism will make it even more obscure (BTW we also use cookies in a somehow buggy way as well for the same reason). Actually, the URL GET string and the hidden form values are used in two completely different contexts. Links on the page use the URL formed with the $get_metric_string variable, but when a user changes a form value or the page is reloaded with either the Get Fresh Data button or after the default refresh interval, the web browser/client just submits the current page (and current form values) to load the page again. and that includes the full URL with all the variables that are needed in there. Without these added hidden form values, if the user navigates from one view to another, then back to the original view, then their previous form value modifications can be lost. This is what the additional hidden form values is trying to prevent, giving the user a more pleasant experience. what I'd seen (and explained above as an incomplete handling of GET variables) is that some links are created missing some of the variables that were set and so the status is lost because the variables were not set in the links as they should had been. there shouldn't be a need to do that through hidden form values if it was done through the URL correctly to begin with. There are two basic ways to navigate around the ganglia website, one way is via explicit A HREF=URL links. The other way, is to change one of the form values, for example, on the cluster view, you can select a new metric to view. When the form selection is changed, this executes an immediate OnChange script, which is always ganglia_form.submit();. Simply waiting the default_refresh interval will also trigger a form submit. Note, the forms in ganglia always begin in the header.php/tpl and always have the same structure: FORM ACTION=./ METHOD=GET NAME=ganglia_form I really don't see the objection to adding the hidden values, since this is the easiest, least obtrusive and best way to do this. Would you really want to make a context sensitive ACTION URL, adding the missing variables explicitly to the different view pages? What exactly is the advantage of doing it this way? This is basically the same thing that happens with hidden form values, automatically added by the browser. Since this is a GET method, the real form variables along with the hidden values are all formed into one long GET string by the web browser and submitted to the server. What exactly is the objection to using hidden form values here? I really don't understand it. They are used in two completely different contexts, there is no mixing of hidden form values with an incomplete GET variables here. One is used in the form submissions and the other in the A links. ~Jason Carlo -- /--\ | Jason A. Smith Email: [EMAIL PROTECTED] | | Atlas Computing Facility, Bldg. 510MPhone: +1-631-344-4226 | | Brookhaven National Lab, P.O. Box 5000 Fax: +1-631-344-7616 | | Upton, NY 11973-5000, U.S.A. | \--/
Re: [Ganglia-developers] Web interface enhancements patch.
On Mon, Aug 04, 2008 at 04:06:07PM -0400, Jason A. Smith wrote: On Mon, 2008-07-21 at 03:07 -0500, Carlo Marcelo Arenas Belon wrote: On Fri, Jul 18, 2008 at 07:33:23PM -0400, Jason A. Smith wrote: This patch takes the max_graphs option from the conf.php file and makes it configurable on the web interface. Not sure if that is the right thing to do, as it would seem that a user configurable max_graphs would make more sense integrated with an already available user configurable show_hosts. Would a separate option that allowed the user to select up to what the admin set as max_graphs be a good idea then? So one option so the admin can set a max for their ganglia server, and another for the user to specify how many they would like to see while in the cluster view. yes, and probably better if that option is overloaded in the current implementation for show_hosts, so that the number of hosts to show can be selected (default to -1 to mean there is no limit). - All of these values are now saved while navigating through the web interface via params in the URLs and hidden form values. Not sure if a good idea, as using hidden form values doesn't allow for URLs that are completely representative of the parameters needed to build the page and therefore will prevent people sending around ganglia URLs that are meaningful. Agree that the URL is getting polluted and this could be a way to solve that problem, but as you point out implicitly in your patch, our current handling of GET variables is incomplete, and adding yet another parameter passing mechanism will make it even more obscure (BTW we also use cookies in a somehow buggy way as well for the same reason). Actually, the URL GET string and the hidden form values are used in two completely different contexts. Links on the page use the URL formed with the $get_metric_string variable, but when a user changes a form value or the page is reloaded with either the Get Fresh Data button or after the default refresh interval, the web browser/client just submits the current page (and current form values) to load the page again. and that includes the full URL with all the variables that are needed in there. Without these added hidden form values, if the user navigates from one view to another, then back to the original view, then their previous form value modifications can be lost. This is what the additional hidden form values is trying to prevent, giving the user a more pleasant experience. what I'd seen (and explained above as an incomplete handling of GET variables) is that some links are created missing some of the variables that were set and so the status is lost because the variables were not set in the links as they should had been. there shouldn't be a need to do that through hidden form values if it was done through the URL correctly to begin with. Carlo - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] Web interface enhancements patch.
On Fri, Jul 18, 2008 at 07:33:23PM -0400, Jason A. Smith wrote: This patch takes the max_graphs option from the conf.php file and makes it configurable on the web interface. Not sure if that is the right thing to do, as it would seem that a user configurable max_graphs would make more sense integrated with an already available user configurable show_hosts. The original intention for max_graphs was probably as a system configuration to reduce the load in the web server to generate all the graphs for a cluster that has way too many nodes and making this user configurable will defeat that purpose. - The number of metric columns in the host view is now configurable in both the conf.php file and through the web interface. Committed revision 1583 for trunk - The default hostcols from the cluster view was added to conf.php. Committed revision 1582 for trunk - All of these values are now saved while navigating through the web interface via params in the URLs and hidden form values. Not sure if a good idea, as using hidden form values doesn't allow for URLs that are completely representative of the parameters needed to build the page and therefore will prevent people sending around ganglia URLs that are meaningful. Agree that the URL is getting polluted and this could be a way to solve that problem, but as you point our implicitly in your patch, our current handling of GET variables is incomplete, and adding yet another parameter passing mechanism will make it even more obscure (BTW we also use cookies in a somehow buggy way as well for the same reason). - Fixed a minor bug where the metric shown in the cluster view wasn't saved while navigating around (wrong variable name). Committed revision 1567 for trunk Carlo - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
