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. 510M Phone: +1-631-344-4226 | | Brookhaven National Lab, P.O. Box 5000 Fax: +1-631-344-7616 | | Upton, NY 11973-5000, U.S.A. | \------------------------------------------------------------------/ ------------------------------------------------------------------------- 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=100&url=/ _______________________________________________ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
