Michael C. Harris wrote: > > Which is why I was trying to clarify what Owen was meaning. If no list > is defined, what does "the "header" hardpoint will have no place to go > in this theme" mean ? And if a theme can define arbitrary hardpoints, > then a plugin isn't going to know where it can put content.
Plugins would not specify where their content is output. The theme configuration page would list the content that is provided by plugins for output, and the site admin would decide to which hardpoint available in the current theme that output should be attached. For example, if a plugin provided "tag cloud" output, it would advertise this via some standard plugin method (and provide an interface for configuration in the same way). An admin could choose to attach this output to the "sidebar left" hardpoint or to the "sidebar right" hardpoint of a theme. When switching themes, the new theme might only have a "sidebar" hardpoint, whereupon the admin would need to assign the "tag cloud" output to that hardpoint, since the old ones "sidebar left" and "sidebar right" don't exist in the new theme. As far as naming convention goes, my opinion is to take a laissez-faire approach to these names. The theme market will decide what the standard names are if they wish to share compatible slots. In the end, using the same names for hardpoints between themes would only be a convenience, not a requirement. > It might be useful to support templates for the hardpoints, for > example sidebar.hardpoint.php, which would typically be an li or a > div. Other templates could $theme->display( 'sidebar.hardpoint' ) > (with appropriate markup, for example inside a ul) and this would then > be called for each plugin that outputs there. I think this is more complicated than it sounds. If a template is provided for a hardpoint, then the variables supplied by the plugin must match with those in the template. That might be fine if the only variable was $content, and the template was simply a wrapper for each thing attached to that hardpoint. But we'll then start to talk about whether each thing should also have a title: <div class="widget"><h4><?php echo $title; ?></h4> <div class="widgetcontent"><?php echo $content; ?></div></div> And then we'll start to talk about whether the widget (used here for lack of another term) should allow plugins to specify the id of the widget div. It's a slippery slope. I think we shouldn't get so complicated as to have to explain to plugins not only what hardpoints are supported, but also what variables are output from within each hardpoint. Instead, I think we should settle with simply what I described before, which is direct output and no adornment of the hardpoint, leaving the plugin responsible for templating of whatever they're offering. At most, we could offer a default template for each hardpoint that would simply wrap any supplied content, and would only support a single variable like $content. If you want to get fancier, your plugin will need to supply its own template, which can be overridden. So the order of template failover could be: 1. Specialized template in the theme matching the plugin call. 2. Specialized template in the plugin matching the plugin call. 3. Generic template in the theme matching the hardpoint name. 4. Generic template in the theme for hardpoints. 5. Raw plugin output. 2-5 would be based on supplying a $content variable to the template. When using a specialized template the template could output any variables that the plugin supplies. >>> The active theme is currently activated in the admin anyway, so that >>> you can configure it. Do we really need to see the available >>> hardpoints of non-active themes ? I'm still not convinced that a >>> function that returns an array of supported hardpoints isn't simpler. I think it would be useful to see what hardpoints a theme supports before activating it, so that I could know whether there was a place to put currently displayed plugin output before activating that new theme. If this information is supplied only via a function, then it will be impossible to know whether there is a place for your tag cloud output before you switch to a new theme. This is not much different from dependency information that the theme might also supply. Owen --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/habari-users -~----------~----~----~----~------~----~------~--~---
