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
1. http://www.csszengarden.com
--
Piers Cawley <[EMAIL PROTECTED]>
http://www.bofh.org.uk/
_______________________________________________
Typo-list mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/typo-list
