I like the idea of decoupling output location from content type, but I
don't think we should implement this narrowly like this.
Until we have full-fledged support, we should hold off. I don't think
we should add a one-time option which isn't pluggable and expandable.
On Sep 26, 2008, at 9:02 AM, Owen Winkler wrote:
>
> 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?
I don't think we should limit groupings based upon content-type. I
think that's the point of this–type should be independent of location.
> 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?
I don't think there need to be a url to display entry/foo post-types.
I think we should redefine multiple templates around 'multiple'. For
individual posts, we would maintain the current 'single' hierarchy.
In themes we would encourage the use of displaying a 'footype.item'
within the foreach loop of the multiple list – thus allowing plugins
to define templates for use _within_ the multiple listing.
I'm sure that might need some refinement, but I think it is important.
Once this is implemented, plugins should be able to provide templates
for both the listings *and* the single. This is especially different
in that different items within the same post list will be using
different templates.
> 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.
Yes, blog software. But blogs frequently include other content, such
as polls or quotes. Look at Chyrp or Tumblr as examples of this: they
both have important content-type functionality which I wish Habari had.
> 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.
I do think we have some compelling reasons: being able to support
different content-types within the same list (chyrp-esque), being able
to "send" content to different places (aside, main chronology, page).
> 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.
Agreed. I think that's definitely the best way to do it.
> 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?
Honestly, I don't think we need to make it as complicated as all that.
Just one more field for each post and a dropdown to select that.
We can then select the posts using the method you outlined.
For the time being, I think we should stick with just creating two
places (main chronology and pages) to start with, and worry about
themes figuring that out later.
> 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.
I do think we need to do this. Though I've outlined reasons above, I
think it is essentially about making content-type support robust.
A system where new content-types are isolated from each other (the
current situation) just isn't what I think we need. When you see the
kind of functionality which Tumblr and Chyrp are offering, I think we
start to see why Habari could use this sort of flexibility.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
