Post vs. Entry
Arthus Erea
Michael H. changed all mentions of entry to post in the admin.
Technically, shouldn't we be using 'entry' to refer to cases where
entries are being referred to and 'page' to cases where pages are
being referred to. Post is a generic term which is used to describe
*all* content stored using the Posts class?
I recommend we standardize this across all of Habari copy with "post"
being used for general cases and specific content type names for
specific types.
Michael C. Harris
That's always been the intent, afaik. Are the specific instances in
the commit you think have been incorrectly changed?
I haven't had a close look at Heilemann's[1] commit, but at least some
of the changes are necessary. For example, changing 'entry drafts' or
'scheduled entry' to post is necessary, because there may be other
content types in draft or scheduled.
I think there's another issue here though, in that 'entries' and
'pages' are our default content types, but they are also concepts;
posts that appear in the timeline and posts that are outside the
timeline. Given that Habari is in fact blogging software, the default
should be that posts turn up in the timeline. But there isn't a
generic way to represent that something should or shouldn't be in the
timeline.
An example of this is the feed. As things stand the feed only includes
entries, so if I publish a podcast (if such a thing were more than
theoretically possible) it doesn't show up. The same may be true for
$posts delivered to the theme, I can't recall.
Does anyone have any ideas as to how this should be represented,
rather than specifically retrieving entries or pages?
[1] I'm using Michael's trac name/IRC nick, because Michael H. doesn't
actually disambiguate him :)
--
Michael C. Harris, School of CS&IT, RMIT University
http://twofishcreative.com/michael/blog
Arthus Erea
wrote:
> the commit you think have been incorrectly changed?
>
> I haven't had a close look at Heilemann's[1] commit, but at least some
> of the changes are necessary. For example, changing 'entry drafts' or
> 'scheduled entry' to post is necessary, because there may be other
> content types in draft or scheduled.
Additionally, many of the copy changes are actually misleading/
incorrect.
For instance, in the dashboard it lists %s posts, when in fact it is
only counting entries. (I have 5 pages and 35 entries. It lists "35
posts")
Someone with commit privileges should go through and check the
specific instances.
> I think there's another issue here though, in that 'entries' and
> 'pages' are our default content types, but they are also concepts;
> posts that appear in the timeline and posts that are outside the
> timeline. Given that Habari is in fact blogging software, the default
> should be that posts turn up in the timeline. But there isn't a
> generic way to represent that something should or shouldn't be in the
> timeline.
>
> An example of this is the feed. As things stand the feed only includes
> entries, so if I publish a podcast (if such a thing were more than
> theoretically possible) it doesn't show up. The same may be true for
> $posts delivered to the theme, I can't recall.
>
> Does anyone have any ideas as to how this should be represented,
> rather than specifically retrieving entries or pages?
>
> [1] I'm using Michael's trac name/IRC nick, because Michael H. doesn't
> actually disambiguate him :)
>
> --
> Michael C. Harris, School of CS&IT, RMIT Universityhttp://twofishcreative.com/michael/blog
different content types are sent.
The proposal outlined earlier would be for there to be different
"content places." (Previous thread:
http://groups.google.com/group/habari-dev/browse_thread/thread/f051ff1992ff710a/d2b79da12798a031?lnk=gst&q=post+location+feed#d2b79da12798a031)
I envision this working through a simple process:
1) Certain content places are registered by themes (main timeline),
system (feeds), or plugins. Something like
"Post::add_new_place('timeline')" where timeline is a unique
identifier for the place. We would standardize some recommended areas
for all places like timeline, feed, sidebar, etc.
2) When a content type is added it includes an array of place posts
for that type should be "sent" to. Something like
"Post::add_new_type('podcast', array(Post::place('timeline'),
Post::place('feed')))" which would associate all podcasts with the
timeline and feed.
3) When posts are fetched at different locations, either by the system
or theme, they would include the appropriate place filters. Ex:
'$posts = Posts::get(array('place', Post::place('feed')))' would fetch
all posts associated with the 'feed' place.
Thoughts?
