[geeklog-devel] Config GUI issues

[Blaine Lang]

Mark R. Evans wrote:
 > Another approach to a two-tiered menu could be to use a select box to 
choose Core, pluign X, plugin Y, or plugin Z.  This removes the need for 
a two tiered approach. Not sure what it gains you, but it would keep 
that section of options from possibly wrapping in the future if you had 
10 or 15 plugins installed that used the configuration API.

Considered that and felt it did not address the issues I was trying to 
solve and prefer an interface where the user can easily scan the tabs 
without having to click and have the screen change. The core site config 
menu is likely the worst case and if we can make the screens and menu 
work for that, then most plugins will work. Once we get 10+ plugins that 
support the online config manager, we will likely need to use a 
Javascript menu to better handle scrolling/wrapping.

 > The current state of the configuration system concerns me a little.  
I understand the goal of using as generic a set of tools as possible to 
allow easy extention and use by plugins.  But, if this is at the 
sacrifice of having a configuration system with selectable options, 
limits and validations, I'm not sure that is the right choice.

Not much validation if any is done today but that is not an excuse. We 
will add config validation functions that allow plugins to extend the 
core config class but we are trying to get this release out. If time 
permits, we can extend the config class the support this now.

 > Since JavaScript is now required to perform configuration, why not 
continue to exploit that requirement and implement some nice pop-up 
windows or tooltips for help or at least duplicate what was in the 
config.php.

This has been discussed and will be added .

 > A user support issues I've seen with tabbed menus is when a user 
makes a change, then clicks on another tab, in this case the change is 
lost. But, in contrast, the story editor, switching tabs doesn't loose 
the changes between the screens.

I'd like to see us move to using AJAX so that changes can be saved 
asynchronously and will offer many other UI enhancements. There was a 
time not so long ago that JS was not allowed in GL code anywhere unless 
the screen worked as well with JS disabled ;)

Blaine