I’ve just been chatting with sprewell on IRC and it occurred to me
that it might be handy to share my current development priorities for
typo with the wider list.
Immediate goals
-
Finish the work on making article publication use a state object
-
Possibly look at making the state object be persistent as a memento
on the Content object
-
Knock off a few more low hanging fruit from the outstanding tickets
list
Medium/Long Term
-
Think more about the right set of states and transitions for
comments and trackbacks (henceforth ‘responses’). I’m pretty sure
that the state machine for response publication isn’t and shouldn’t
be the same as the machine for article publication.
-
Experiment with having multiple selectable state
machines/publication policies for responses, so one policy might be
‘open door’ where everything gets published, another might throw all
responses into a ‘pending approval’ queue, another may publishe all
ajax comments and throw the rest into the pending approval queue or
whatever.
-
A Bayesian trackback spam stopper
-
Make page caching work right. Back in 2.6.0 days, page caching was a
huge pain in the bum, but by ghod Typo was fast when it was
working. As I outlined in an earlier post, I think the Trigger
system will allow us to get the benefits of future publication and
expiring sidebars alongside the speed boost of page caching, but
it’s not straightforward.
-
Document our APIs. I’ve tended not to do much in the way of
documentation because I’m far from sure that the APIs are stable
enough for it not to be wasted effort. However, I’m starting to
think that the new Sidebar API might stick around for a while and
could use some documentation. (But I need to write a non-trivial
sidebar to be sure of that I think…)
-
Give the Theming system a long, hard look. I’m inclined to adopt
something like the Scribbish document structure – having seen the
kind of things that can be accomplished with CSS at the CSS Zen
Garden[1] I want to make sure that our default markup is as friendly
to that sort of modification as possible.
Of course, there will always be a space for the kind of advanced
themes that need to change the markup, and I want to make life
easier for those too. I think there’s a case for allowing themes to
have parameters akin to sidebar parameters, but that needs some
careful interface thought – it shouldn’t be impossible to hang
theme parameters off the blog’s settings though.
-
Blog settings need some thought too. If we do go all the way to
multiblog capability (still open for debate), then we’ll need to
pull some settings out of the settings hash and up into the blogs
table proper (at the very least we’ll need to pull any settings that
are used by the router to determine which blog a given url maps to
up to the table so they can be accessed with a simple sql
query). Also, it seems that the settings hash could benefit from
being multilevel (one obvious case for this is in the default
settings for various content objects, currently we have
‘comment_default_allow_pings’, ‘article_default_allow_pings’,
‘article_default_allow_comments’ and what have you. Wouldn’t it be
cool if you could do:
Article.with_scope(:create => this_blog.defaults_for[Article]) do
…
end
Admittedly, it’d be cooler if you didn’t have to do that, but could
simply let this_blog.articles.build(…) handle it for you,
but… baby steps…
-
Textfilters. I really, really, want to rework text filters so
they’re not controllers.
-
Er…
-
That’s probably not all, but it’ll do for now. Did I miss anything
- http://www.csszengarden.com
Piers C. a écrit :
on the Content object
be the same as the machine for article publication.
- Make page caching work right. Back in 2.6.0 days, page caching was a
could use some documentation. (But I need to write a non-trivial
easier for those too. I think there’s a case for allowing themes to
query). Also, it seems that the settings hash could benefit from
Admittedly, it’d be cooler if you didn’t have to do that, but could
- http://www.csszengarden.com
Hi list,
I come from the Wordpress world where I’ve developped some themes and
plugins.
For the spam thing, we have a very powerfull engine made of several
plugins called Spam Karma. The code is pretty neat, and I don’t think it
would be difficult to port it in Ruby.
With all the filters, there is also a centralized blacklist database
that can be used as well.
Spam Karma code is avaliable at
http://unknowngenius.com/blog/wordpress/spam-karma/
Regards,
Frederic
Piers C. [email protected] writes:
I’ve just been chatting with sprewell on IRC and it occurred to me
that it might be handy to share my current development priorities for
typo with the wider list.
[…]
Medium/Long Term
[…]
-
Textfilters. I really, really, want to rework text filters so
they’re not controllers.
-
Er…
-
That’s probably not all, but it’ll do for now. Did I miss anything
Yes, it seems I did:
-
Admin plugins. Rework the admin interface so it’s easy to add a new
admin tab as a plugin. That way we can experiment with things like
spam handling/blacklisting or whatever in a way that’s (hopefully)
decoupled from the rest of the administrative interface. It would
also be good to be able to add actions to existing tabs in a neat
fashion. Things like the podcasting addons have the potential to
work rather neatly as a plugin
-
‘Whole body’ plugins. Thinking about the possibility of making the
podcasting addons into an admin plugin, it occurs that really it
would need to be more than that because there’s also user visible
feeds to worry about. It seems there’s a case for at least working
out a standard directory structure and registration system for
plugins so that they can integrate themselves with the wider Typo
system.
Gary S. [email protected] writes:
- ‘Whole body’ plugins. Thinking about the possibility of making the
podcasting addons into an admin plugin, it occurs that really it
would need to be more than that because there’s also user visible
feeds to worry about. It seems there’s a case for at least working
out a standard directory structure and registration system for
plugins so that they can integrate themselves with the wider Typo
system.
Now that’s an exciting concept … you read my mind because I’d just
asked myself “What about a plugin architecture?”
Heh. I’ve got the idea in my head now. I dunno when I’ll do something
about it, but once something is named it’s much easier to work on it
unconsciously.
How will you handle having plugins register routes or are you
contemplating
making a ‘typo plugin’ versus the regular ‘rails plugin’?
On 13 May 2006, at 12:15, Piers C. wrote:
podcasting addons into an admin plugin, it occurs that really it
would need to be more than that because there’s also user visible
feeds to worry about. It seems there’s a case for at least working
out a standard directory structure and registration system for
plugins so that they can integrate themselves with the wider Typo
system.
Now that’s an exciting concept … you read my mind because I’d just
asked myself “What about a plugin architecture?”
Gary
“Steve L.” [email protected] writes:
How will you handle having plugins register routes or are you contemplating
making a ‘typo plugin’ versus the regular ‘rails plugin’?
Dunno yet. Plugins are definitely in the ‘blue sky’ phase of planning
at the moment.