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=100&url=/ _______________________________________________ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
