On Thu, Sep 04, 2008 at 04:53:45AM -0700, Arthus Erea wrote: > > On Sep 4, 3:31 am, "Michael C. Harris" wrote: > > On Tue, Sep 02, 2008 at 09:50:51PM -0400, Owen Winkler wrote: > > > > > Michael C. Harris wrote: > > > > > 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.
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. > > > 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. People aren't going to know what hardpoints they're currently using. Unless we provide a list of them on the page. > Plus, XML is usually pretty readable–certainly easier than a set of > arbitrary function calls. I'm not sure where the "arbitrary function calls" comes from. I was talking about a function call that returns one array of hardpoints. Just to be clear, I'm playing devil's advocate so that we make sure we're getting the best outcome we can. -- Michael C. Harris, School of CS&IT, RMIT University http://twofishcreative.com/michael/blog IRC: michaeltwofish #habari --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
