Remember this:
http://www.mail-archive.com/[email protected]/msg02284.html
Well, once I've checked in my current local branch which implements a
feedback specific state machine, we'll have hit most of those goals,
so it's time to think about a few more.
Outstanding/Short Term
----------------------
* Finish working through the implications of the new state machine
based content 'state'. Essentially, 'published?', 'spam?' and a few
other flags are now delegated to the content's state. Any behaviours
on an object that do anything like:
if self.published?
...
end
should have the '...' turned into a method on the state objects and
get rewritten as
self.state.meaningful_name_for_some_behaviour
* Something similar applies to some of the things the controllers are
doing. Structural code (where controllers treat objects as nothing
more than data structures) is anathema, behaviour should be pushed
to the model where it makes sense. Controllers shouldn't access the
state directly, so state dependent behaviour should be pushed to the
model first and then delegated to the state object.
* Various of the delegated query methods could usefully be added to
the model's table, to help with searching. For instance, it would be
useful for the feedback page to list only those items which are
probably spam. Which means adding 'spam' and
'classification_is_certain' (lousy name, need to find something
better) booleans to the contents table to help with
searching. (Controllers don't (and shoudln't) know about the state
objects, they just know about the query methods, so we need flag
fields corresponding to the query methods which can be used as find
conditions)
* Make page caching work right. Still on my todo list, but not quite
so urgent as it was. It's in this section because it's one of the
things that haven't yet been done from the last goals post.
* Give the theming section a long hard look. Yay! We have Scribbish in
the core now. However, theming still needs looking at. Wouldn't it be great
if you could just drop a theme in vendor/plugins and have it appear
in Typo's list? Wouldn't it be handy to support theme specific
configuration? Woudln't it be useful if all this was documented?
* Blog settings. Hmm...
* Text filters not being controllers.
Scott's doing some work on making url_for work without having to get
at the current controllers all the time. Once that's done it should
be a great deal easier to turn textfilters into models. Again, it
would be good to be able to write textfilters so they could be
dropped into vendor/plugins
New stuff
---------
* Authentication. I've posted about this before, but we should really
support, at the very least, OpenID as well as our own internal users
table.
* Authorization. Once we can authenticate, we can authorize. Some
blogs might choose require authentication before allowing anyone to
comment, or automatically mark any unauthenticated comments as
PresumedSpam
* Pluggable Spam classification. Right now, when feedback is created,
it's in the 'Unclassified' state. Saving it 'collapses' it to one of
'PresumedSpam' or 'PresumedHam'. The method for doing this
classification is currently hardwired. First we check our own Spam
Protection library, then, if it's turned on, we ask Akismet.
Which is all very well, but what happens if we decide we want to use
Authentication as a factor in classification? What if someone writes
a captcha plugin (which gets no nearer to Typo than vendor/plugins
dammit)?
So, we need to think about making the classification system into a
dynamic pipeline attached to the blog. My current thinking is that
this would be configured like sidebars are now (though possibly not
at the model level, about which more later). The administrator would
be presented with handy drag and drop interface and drag
classification tools into a pipeline. So, I might have a pipeline
that looks like:
is_logged_in -> article_age -> blacklist -> akismet
While someone else could have
captcha -> article_age -> blacklist -> presume_ham
each engine in the chain would look at the feedback and return one
of :ham, :spam or nil, where returning a symbol halts the
classification process, otherwise the feedback goes to the next
classifier in the chain. Something similar could be done at the
point that spam is firmly classified by the administrator; each
engine would have their #report_as_spam/ham(feedback) method
called and they'd do the reporting as they chose.
* Multiblogging. I'm so in two minds about this. I think it's going to
happen, and I *don't* think it's going to have an enormous impact
on the performance or copmlexity of the rest of typo. Introducing
the blog object has proved to be The Right Thing, for all its
teething problems.
* RESTful API. I like REST. It just makes sense to me. But Typo
isn't all that RESTful. Article permalinks are, of course,
sacrosanct, but pretty much everything else is fair game. In the
long term, I'd like to see the back of admin/* in favour of moving
administrative behaviour up into top level controllers and slightly
more complicated access control. This is definitely branch
territory, if only because the support for the sort of thing I'm
thinking of has only recently gone into edge rails.
* Migrations. Migrating is hard. It's hard to keep the migration
scripts up to date. So, I propose firming up the various message
posting protocols we have, documenting them, and then sticking to
them both in our controllers and any migrations we use. I envisage
using something like the Atom API as our basic posting protocol.
* Implement the Atom API.
* Use the rails plugins directory. If you write textfilter, or a
sidebar, you want some easy way of distributing it. And we want not
to have to stick it in the core distribution. It seems that the best
way to do this is to enable writing plugins that can be installed in
the same way as any other rails plugin. I *think* that this can
already be done, but it's completely undocumented. We need to
investigate this and, if it will work with the current state of the
art, we need to write generate tasks to allow a plugin developer to
do:
./script/generate sidebar|textfilter|theme
and have a framework dropped in place so she can get on with the
hard work of making it do something interesting.
* Investigate other blogging engines' plugin architectures. See if
we're missing any capabilities and what we'd need to do to import
any useful stuff into Typo.
Hmm... that'll probably do for now. Did I miss anything?
--
Piers Cawley <[EMAIL PROTECTED]>
http://www.bofh.org.uk/
_______________________________________________
Typo-list mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/typo-list
