On Sep 4, 3:31 am, "Michael C. Harris" <[EMAIL PROTECTED]>
wrote:
> On Tue, Sep 02, 2008 at 09:50:51PM -0400, Owen Winkler wrote:
>
> > Michael C. Harris wrote:
>
> > > An implementation question (or four); what would themes advertise in
> > > their XML ? A variable to fill ? A selector of some kind, like a CSS
> > > ID ? What advantage would having them in the XML give us, as opposed
> > > to a standard function call to, for example, hardpoints() ?
>
> > The advantage to having it in the theme's XML is that you can know about
> > the places to which a theme supports output before activating the theme.
>
> That sounds like a good reason.
>
> > Our interface could highlight the hardpoint names that are in use. For
> > example, the listing for a theme named Aardvark could look like this:
>
> > Theme name: Aardvark [Activate]
> > Supported Hardpoints: *sidebar* footer ?header?
>
> > "*sidebar*" would be bold (or something) indicating that your current
> > theme outputs data to that hardpoint. "?header?" would be red (or
> > something) indicating that the data output to the "header" hardpoint
> > will have no place to go in this theme. Or something useful like that.
>
> It sounds like you're suggesting that the core would define a list of
> hardpoints, plugins would send output to a particular hardpoint by
> default, and theme authors would choose to support some subset of the
> listed hardpoints, which would be advertised in the XML. Users could
> override the plugin's default hardpoint and choose to have the data
> output to a different hardpoint. Is that what you're meaning ?
Actually, as I understood it we wouldn't define any hardpoints in the
core.
Instead, we would "recommend" that certain naming conventions be used,
but allow themes to define their own hardpoints–this is a much more
flexible approach.
The idea of having the interface listing your active theme's
hardpoints would be to show you which ones the theme does in fact
support.
Given this model, I see so need to develop an arbitrary list of
hardpoints which theme authors must choose from.
> 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.
Yes, I think a system similar to that would be developed.
You could then pass variables to the hardpoint ($template->title=
'Foo') so a common look could be preserved.
> > The key point being that if you rely on what functions are called to
> > know what hardpoint names are available in the theme, then it becomes
> > difficult to know what they are without activating the theme first.
>
> 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.
Actually, I think we probably do. That's what supplies the
functionality of being able to see if a theme you are about to
activate will support the hardpoints you are currently using.
Plus, XML is usually pretty readable–certainly easier than a set of
arbitrary function calls.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
