[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: <http://eight.pairlist.net/pipermail/geeklog-devel/attachments/20080104/5d793a52/attachment.html>