Randy Walker wrote:
>
> So what does this mean? It means that if you want a new Poll, you can
> choose to have it mixed in with your blog entries, or you can have it
> stand-alone. Or any other content type. Currently, when you want a
> Page, you just get "text". You don't get any of the options you get
> with a content type.
It's an interesting idea, although I think it's not complete.
Basically, you're adding a flag that says "This post is part of The
Chonology", and then you let the theme construct the list of things to
display based entirely on whether it's part of The Chronology.
Why limit groupings to just one? Why limit groupings based solely on
which content types they belong to?
Also, this has significant implications with themes, since themes now
get the posts they want directly, and templates are based more on what
they're displaying than what magnet draws posts toward them. For
example, if you put "entry" and "foo" content types into The Chronology,
what template is used to display them when they're displayed together in
a list? entry.multiple? multiple? entry.foo.multiple? And what URL
allows you to display just entry/foo post types, if any?
Another thing to consider is whether users will really need to add
content types to any specific output. I'm not sure whether we need to
provide an interface for this, and if we did, what specifically we
should allow users to select with it. First and foremost, Habari is
blog software.
While I would want to keep its API as robust as possible, I don't yet
feel we have a compelling reason to start building that interface into
core (which is where I think it should be if it exists at all) to allow
users that granular control over what things go where.
Regardless of that, I'd been considering the idea of post query
"presets" for a while. Our mechanism for Post::get() allows the passage
of an array of values. If we serialized that array and stored it using
a specific name, we could refer to that preset using some syntax like:
$posts = Posts::get(array('preset'=>'chronology'));
The presets themselves could be defined by the user via an advanced
interface. This would offer more flexibility than just a checkbox, but
also implies a lot more. The interface for constructing these would
need to be pretty solid, and we'd need some default names to use so that
themes could take advantage of them. Themes would also need to publish
(in their XML) what presets they support.
In Drupal, the views module is used to negotiate this. Has anyone seen
the complexity in there? Is that what we're looking to add?
The suggested method might be the simplest way to accomplish whatever it
is that we're trying to do, yet I think someone needs to explain the
intent and objectives a bit more, compare them to the scope of the
application, and see if we even should do this before we spend a
reasonable amount of effort solving the above issues and determining if
that's the extent of the functionality that we want to provide.
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
-~----------~----~----~----~------~----~------~--~---
