While I agree that we need to allow the user to completely replace the system with a custom one, I don't agree that the only UI should be from a plugin. This is a core feature of Habari and as such there should be a well thought out UI for interacting with it. I think that this should be a simple system, that shows the power of the taxonomy system. Since subpages are such an oft-used feature, I think it makes a great deal of sense to have the core UI we build for taxonomy implement that feature.
Chris On May 22, 2009, at 9:50 AM, Owen Winkler wrote: > > Ben Lagoutte wrote: >> >> The WP comparison stops here. I guess if habari was to have something >> like that, it should be a smarter approach than just a free field >> like >> Wordpress did. That would put habari above WP in that area too. > > Habari will probably not have a "page order" field. The in- > development > code for Taxonomy allows the system to define multiple MPTT (modified > preorder tree traversal) structures that describe trees of > organization. > > Each of the structures in the taxonomy is called a "vocabulary" and > has > a name. A Vocabulary can be defined with a required one-to-one > relationship with posts. > > What this lets you do is define a Vocabulary named "products", and > then > create a tree of Posts, each with its own title (it can just be the > Post's title, or it can be something else entirely). Using the > functions in the Taxonomy-related classes, you should be able to > retrieve a list of posts that have been associated with that > vocabulary, > and in an order that allows you to build a menu or a structured > ul/ol-type list. > > The call for Posts::get() should also be modified to return posts that > qualify for specific taxonomy characteristics, but will probably not > return posts in a tree structure (although they may be properly > ordered). A separate call (as I mentioned above) using > Vocabulary::get_term() will return a term that has methods to iterate > through the tree of that vocabulary and obtain the linked Post to each > term. A helper method like Vocabulary::get_object_tree() could > probably > return the Posts with an ordered "children" property. > > The evolving API definition for Taxonomy is here: > http://wiki.habariproject.org/en/User:ringmaster/Taxonomy > > The implications of this are that you could create multiple > vocabularies, one for each menu you want to create. Each vocabulary > can > contain any posts, so a post can exist in a single menu more than once > and a post can exist in many menus. > > You could do crazy things with this system like build one primary > menu, > then build multiple secondary menus, and only display one secondary > menu > based on the Scope (using our blocks/areas/scopes features) of the > page > displayed. > > As an example, if you're Nike, you'd have a primary menu with "Shoes" > and "Sportswear", which are also complete secondary menus unto > themselves. When displaying pages that qualify in the "shoe" scope, > you > could display the "Shoes" secondary menu in a sidebar block, and > likewise use the "Sportswear" secondary menu instead on a page showing > basketball shorts. > > Building the underlying system properly is really important to us > right > now. What you'll find missing in the system so far is a way to use > the > UI to set any of this. Suggestions for this are welcome, although I > think for our first iteration (although the more I think about it, the > more I think this may be a permanent condition) the only UI for > Taxonomy > will be via plugin. That means that if you want a menu that you can > configure, you'd activate a plugin for that. > > Eventually, we'll probably include a default menu plugin in the > distribution, but because the system I've described above is so > flexible, we'd want to give users the option to disable any native > menu > system completely to replace it with a custom system that either comes > pre-packaged from the extras repo or from a custom code developer. > > The conversation I've had many times with many people is that > "Taxonomy" > as an idea is much too complicated to expose some kind of generic > interface and let the end-user sort it all out. We'll include some > basic plugins that make use of the underlying system, but we'd > probably > be well off to never have an interface element that says "Create a new > vocabulary", since that could mean many things depending on how it's > implemented. > > I hope that gives some impression of the plan that we're trying to > implement with sub-pages and navigation. There are still some sticky > bits, as I said, with UI and also with URLs. I know everyone says > that > they want /grandparent/parent/child URLs, and figuring out a clean way > to both allow and generate those (and in my opinion, whether you'd > even > need them) is also an interesting challenge. > > Pitch your ideas here. > > 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-dev -~----------~----~----~----~------~----~------~--~---
