Couldn't agree more. That's a great system you've described... the
best thing about it is that it isn't hardcoded to support a specific
number of sidebars (like many other "widget" systems).
With a system like that, the entire theme could potentially be
constructed from various hardpoints. This would also solve the problem
of plugins being able to "send" content to the main header or the
homepage.
I agree: we should get 0.6 out the door, then focus on themes for 0.7.
Perhaps we could coordinate a theme design contest with 0.7?
On Sep 2, 8:17 am, Owen Winkler <[EMAIL PROTECTED]> wrote:
> Michael C. Harris wrote:
>
> > If both plugins use a template the theme can just
> > $theme->display('blogroll') and it will display whichever one is
> > activated, no editing required. Also, if the theme supports it but
> > there is no plugin activated, there will be no output.
>
> This works, of course, but isn't a long-term solution.
>
> Instead, what we should do is allow themes to advertise (via their xml
> definition) what places they allow custom content to appear. In the
> past I've called these "hardpoints" - in aeronautical terms, "A
> hardpoint is any part of an airframe designed to carry an external
> load." (Wikipedia)
>
> Likewise, plugins could advertise what content they make available for
> attachment to hardpoints using API calls. And since themes are
> themselves a sort of plugin, they could also make available their own
> content for placement.
>
> Somewhere in our admin UI, probably around the theme selection page or
> settings page, we would provide an interface for site admins to match
> those plugins' output with hardpoints in the theme. Then if you change
> themes, you don't need to edit code, you simply attach the content to
> the hardpoints in the new theme.
>
> Call it blocks. Call it widgets. Call it content places. Call it
> whatever you like, this functionality is available almost universally in
> themes in other platforms, and I think it's a great way to get the
> extensibility we need.
>
> Now, there is going to be some concern that when a plugin supplies
> output to a theme that the styling and coding of the plugin's output
> will not match the theme. This is a real and valid concern, but one
> that we can mitigate through code that we already have in place.
>
> Plugins that produce output should include a template file for that
> output and register it with the system. This will be used for the
> default output that they produce. Any template produced this way can be
> overridden by including a file in the current theme with an identical name.
>
> So for themes that want to support styling for specific plugins, they
> can include templates. For users who want to style plugin output when
> this output isn't provided for their theme, they can build a new
> template specific to that theme and include it in the theme directory,
> and this will not affect the default plugin output (unless they
> overwrite that purposefully) or the output of the plugin in other themes.
>
> This is a feature I was hoping we'd get in 0.7, when we really get to
> business making the theme system perfect.
>
> 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
-~----------~----~----~----~------~----~------~--~---
