Interface Question


#1

So, I’m just tidying up the publication semantics by adding a
published_at field to Content, and adding a Trigger class, which fires
off events at specified times in the future (or as soon after the
specified time as possible).

The workings are slightly ugly at the moment, but the upshot of this
is that articles.published is only true for articles which are both
marked as published and have a ‘published_at’ time in the
past. Pending articles are have a future published_at attribute, a
false ‘published’ flag and an entry in the triggers table set to fire
on the first request after the published_at time.

The idea is that notification, remote pings and cache invalidation all
get pulled out of Content and into appropriate observers (Notifier,
Pinger and the current CacheSweeper spring to mind as decent names),
which only fire at the point when an article is actually published
(using a ‘just_published?’ flag). Which means we also get to DRY up
the various places which trigger notifications/pings (they’re
currently triggered in Admin::ContentController and various of
webservice implementations, and they sometimes trigger at the wrong
time).

So, with that in mind, I’m canvassing opinions on what people expect
from /admin/content…

If you post an article and don’t mark it as published, but do set a
‘Publish At’ time, do you expect it to get published at the requested
time? I’m assuming ‘yes’ for the time being.

NB: For the “Can’t we just have a stable release?” crowd. The stable
release is currently blocked on Scott’s work on making Typo
installation rather more friendly and is independent of the work I’m
doing on publishing semantics. The publication semantics work is
because, at present, the notification/remote ping system is broken in
the face of future publication times – notifications get sent before
the article is visible on the blog, which is flat wrong. It’s also to
do with code quality; by adding various observers we can get rid of a
fair amount of code duplication and ‘structural’ code[1]

  1. Structural code is code which treats an object as a data
    structure – never a good sign.

#2

On 10 May 2006, at 12:10, Piers C. wrote:

If you post an article and don’t mark it as published, but do set a
‘Publish At’ time, do you expect it to get published at the requested
time? I’m assuming ‘yes’ for the time being.

I use an external blog program so I’d never have a use for this. I
save drafts in Ecto. I can’t understand why people would want to
queue up a load of posts. Going on holiday? Then have a break until
you get back :wink: But if somebody wanted it I guess it would be ‘yes’
as well.

I do really see where you’re going with trying to be as DRY as
possible though … very good.

NB: For the “Can’t we just have a stable release?” crowd. The stable
release is currently blocked on Scott’s work on making Typo
installation rather more friendly and is independent of the work I’m
doing on publishing semantics. The publication semantics work is
because, at present, the notification/remote ping system is broken in
the face of future publication times – notifications get sent before
the article is visible on the blog, which is flat wrong. It’s also to
do with code quality; by adding various observers we can get rid of a
fair amount of code duplication and ‘structural’ code[1]

I see Scott’s feed getting completely republished every so often so I
guess that’s to do with his testing :slight_smile: Typo r1041 is pretty stable
for trunk though. I’m managing to use it.

I know exactly what you mean about notifications being broken. If
Typo runs into a rails error when I’m posting (normally something to
do with text filters) then I still get the notification that there is
a new post even though the published flag isn’t set … it’s like
that flag is the very last thing set. So it would be very nice to
see notifications working properly.

Gary


#3

Gary S. removed_email_address@domain.invalid writes:

I know exactly what you mean about notifications being broken. If
Typo runs into a rails error when I’m posting (normally something to
do with text filters) then I still get the notification that there is
a new post even though the published flag isn’t set … it’s like
that flag is the very last thing set. So it would be very nice to
see notifications working properly.

The plan is that notifications only get sent after an article has
been published and successfully saved to the database. The idea being
that it’s better to publish successfully and not send the
notifications than it is to notify but not to publish.