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
-~----------~----~----~----~------~----~------~--~---

Reply via email to