[geeklog-devel] Plugins and GL 1.5 online config manager

[Aaron Blankstein]

On Jan 3, 2008 11:39 PM, Joe Mucchiello <joe at throwingdice.com> wrote:

> site_enabled still needs to be removed from the list of configuration
> options since once you set it to false, you can't login to reset it.
> Moving it to db_config is the least painful option.
>
> At 09:52 PM 1/3/2008, Blaine Lang wrote:
> >With GL 1.5 and the online config manager, plugins that want to use
> >it have to do things a bit different and I've re-worked the
> >staticpages plugin installation and upgrade code to support loading
> >the online configuration. What's needed now is peer review to see if
> >this is the best way as it would likely be copied into other plugins.
>
> Peer review now is a bit late in the game. Where was the design
> document's peer review?
>
> I have a related question. Where do the configuration pages for the
> plugins reside? I can imagine the configuration tab being extremely
> confusing if it is a mixture of core tabs and plugin tabs. Especially
> if complicated plugins need 4-5 tabs themselves.


A complicated plugin with 4 or 5 of it's own tabs will be only one tab in
the top level, that's why a two-tier menu is being used.


> I'm not sure the
> config class should be written as a singleton. There should be a core
> config object and each plugin should create its own. That way when
> you go the staticpages admin page, one of the top menu items would
> "configure".
>

The situation you describe does not require an object for each class. The
class being a singleton prevents
over querying the database which I think is a beneficial quality.

I also notice you have to be in 'root' use the config gui. That makes
> sense for options in the old config.php but by moving the
> configuration to a GUI, it should be more flexible.
>

I agree.


> At 11:11 PM 1/3/2008, Blaine Lang wrote:
> >I think the change would need to be made to the COM_whatsNewBlock as
> >we have no specialized handlers in the config class.
>
> This is a huge design flaw. There's also no validation code. Suppose
> I have a field that can be between 1 and 100. My only choice is to
> make a ridiculous dropdown box. Or go with a number field and handle
> out of bounds values "gracefully". At a minimum, the "selectarray"
> field should be able to handle other simple validations: if type =
> number, selectarray contains a two-element array of lower and upper
> bounds (or is empty if all values are allowed).
>
> Special handlers would work if the class was a real class and each
> plugin could subclass it for maximum effect.


PHP4 and PHP5 simultaneous compatibility makes using subclasses extremely
difficult here.

-- Aaron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist8.pair.net/pipermail/geeklog-devel/attachments/20080104/5d793a52/attachment.html>