User talk:Arthus/ThemeConfig

From Habari Project

Jump to: navigation, search

Share thoughts/suggestions here.

Morydd's suggestion on IRC to use themer-friendly names notwithstanding, it might be beneficial to look at solving this problem with code that we already have.

Currently, themes can provide configuration via the same (or very similar) hook that plugins use to provide configuration. This can be via FormUI, which is our preferred method of form generation because (for one reason) it has the advantage of allowing plugins to add things to the theme config UI via the action_modify_form hooks.

Rather than build an interface system dedicated to processing the XML in the theme.xml, consider a capability that would allow the passing of the <config> section of the theme.xml to FormUI directly for form generation via, say, a $form->build_from_xml() method. This would be doubly useful in that it could also be used for plugins to lazily produce forms in xml that could yet be overridden via the action_modify_form hooks, while re-using all of the form intelligence that we've already built into FormUI.

The most efficient and flexible way to do this from a code and documentation point of view is to use the existing FormControl subclasses as the type attribute of the field, rather than the names listed in this proposal. In addition, the other attributes of the tag would be passed forward to the control class. The benefit is twofold:

  1. There would be no need to translate between the names listed and actual FormControl subclass names. If the type is "FormControlText" (or just "Text" if we require that all FormControl classes are prefixed with "FormControl", which is currently not the case, but in my opinion, a reasonable restriction) and that class exists, then that type of control is created.
  2. User-defined controls can be written and used in the form for the theme config. What I mean by this can best be described with an example. While we would likely create a color-based control to accommodate core color selection needs for this feature, we currently don't offer one. If that was generally the case, a theme or plugin could provide a FormControlColor that would implement this, and specifying it in the XML would simply create it as usual. And custom control could be created in this way, which would be very useful for creating non-standard controls that seem endemic to theme design.
  3. Documentation is virtually built-in. Since any properties that apply to the FormControl subclasses also would apply to the XML, documenting their use would only need to happen once, with perhaps an extra example for each control to show how it would be used as XML. The core documentation effort would be shared between the instances, rather than having to document each construction completely separately, each with different features.

The downside to this approach is that the type attribute would not be as friendly as Morydd suggested, but I think the flexibility at the cost of having to look up control type names is worth it.

To clarify, I am not suggesting that we abandon the suggested XML schema in favor of forcing themers to code. On the contrary, this seems like a logical simplification for that type of user-developer. Instead, I'm suggesting that we apply a beneficial expansion to the code we're already using to enable that functionality.


It was always my intention to use FormUI from the backend. This would definitely include some kind of hook/action, so plugins (or the theme) can modify the resulting form.

When creating the proposal, I tried to keep three goals in mind:

  1. It should be as easy as possible to add configuration. You shouldn't need to touch theme.php to do so.
  2. There should be a consistent UI for configuration across all themes.
  3. Plugins should be able to modify the configuration.

I believe using FormUI accomplishes all of those goals, but I do think some level of XML abstraction should be in place. It definitely seems worthwhile to use some sort of $form->build_from_xml($xml) where $xml is a SimpleXML object.

Here is my proposed workflow, for when the configuration panel is requested:

  1. Core code creates a new (empty) FormUI object.
  2. Core code calls the build_from_xml($xml) method of the FormUI object, passing the <config> node of theme.xml
  3. Core code adds "submit" and "reset" buttons, for saving the config and for resetting to defaults
  4. Core code calls the 'theme_config_form' action, which allows plugins (or the theme) to modify the form

Within the build_from_xml function, I think standardizing on the control type names would be beneficial. The only action I think we should do is ucfirst() the type and prepend 'FormControl', then pass everything on to FormUI. I agree that most everything else can be handled by FormUI. The ability to add custom controls is definitely an added benefit, especially since themes would be able to package in controls for any non-core components they include. (But I do think we should add the suggested types from my proposal to core.)

The one thing you didn't address was how we would handle the output side. This is where we'd probably have to add some intelligent theme code, which would query the database. If nothing was found, it'd look for a default in the theme.xml file.

The one problem I see is with more complicated control types, such as <select>. Where would we process the xml? In the control or in the theme?

--arthus 00:20, 27 April 2009 (UTC)

I am pulling out the extendable parts, since at this point they seem like a distraction. We should think about adding them back later. arthus 00:32, 27 April 2009 (UTC)

Having changed the spec, I see the XML being interpreted like this:

  1. The main <field> node is scanned for attributes.
  2. A new FormControl is created, using the type, name, and caption values of the <field>
  3. The <field> node is scanned for any child validators. If any validators are found, they are added to the $field, with any attributes being passed along.

arthus 00:34, 27 April 2009 (UTC)

Personal tools