On Sep 2, 2008, at 3:20 PM, msi wrote:
> > On 2 Sep., 14:17, Owen Winkler <[EMAIL PROTECTED]> wrote: >> 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. > > This is a very good one. It could actually solve the problems because > the theme author has not to decide a bunch of plugins, he like. That > is the problem, I see at this time. When I would write a theme, I > would use the plugins, I like most, and I would support them of > course. If a user is not happy with it, he/she has to edit the files. > > With your approach, Owen, this is not a problem anymore, because I > would declare some kind of "useable space" and the user can decide > what to display there. Sounds like an awful lot of work but this would > really k*ck a**. ;-) > > > @Arthus, you are in to this one, right? Actually, this is some kind of > a guideline, a plugin author or a theme author has to respect. And > there is nothing wrong about it. Whatever "massive extensibility" > means, or whatever your goal is, you also have to make sure that there > is some kind of a minimum standard. Just take some time and read the > different communities (say: of WordPress, for example). You will find > a lot of simple questions. Simple for you and for me. But difficult > for non-experienced users. I do not blame them. But I just want you to > get their point of view. They just expect a software, installable, > easy to use, etc. I am completely in support of Owen's proposed system. The very reason I have such support for it is _because_ it is about allowing extreme extensibility. In the core, we wouldn't be locking any plugin into going to the "sidebar" – likewise, themes could allow plugin output wherever they think it fits best. > As a developer, it's also your job to guide the authors of all plugins > or themes. It would not be problem for me to follow a strict rule when > I write a plugin. Actually, it would make it easier because I clearly > know what to do and what not to do. This is how I think about it. Yes, we would certainly recommend that themers support content areas. We would probably even develop a set of "recommended" naming conventions (sidebar, header, etc.). Likewise, we would recommend that plugin developers allow output to be done through this system. But we don't require it... if a particular developer doesn't like this system then they are free to choose another. Nothing keeps them from doing so, and nothing should. In the end, it is about us building a robust system and encouraging developers to tie into it. By tying into it, that can be touted as a feature of their theme/plugin. (Hence giving them a reason to.) It's all about offering best practices rather than required standards– putting the power in the hands of the user/developer. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
