Forum: Typo Interface Question

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
0196ff65610046d2f8ba58bc4a45f144?d=identicon&s=25 Piers Cawley (Guest)
on 2006-05-10 13:11
(Received via mailing list)
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.
D6f24842b973de6cb75203c4c57dfbcb?d=identicon&s=25 Gary Shewan (Guest)
on 2006-05-10 13:33
(Received via mailing list)
On 10 May 2006, at 12:10, Piers Cawley 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 ;)  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 :)  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
0196ff65610046d2f8ba58bc4a45f144?d=identicon&s=25 Piers Cawley (Guest)
on 2006-05-10 14:00
(Received via mailing list)
Gary Shewan <gpsnospam@gmail.com> 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.
This topic is locked and can not be replied to.