Renamed the Action functions to throw an exception like it. I still
think it probably makes sense to have the callback defined in both
places for finer control.
The classes/ subdir is primarily for the DB_DataObject classes. Stuff
in there can get stomped by various generation scripts.
I've moved the lurkers there -- related to command-handling -- to
lib/. Since auto-loading works fine with lib/, there shouldn't be much
of a visible change here.
We try to handle DB_DataObject errors a little bit better. Previously,
they just spit out a cryptic string to the browser with a suggestion
to turn on debugging (not a good idea!). So, we catch the error, write
the full error message to the log, and then tell users that the can
contact the admins if they need to.
I got a little sick of trying to keep the export data and <head> links
synched in actions, so I made a common method, getFeeds(), which gets
the feeds for both. It returns an array of Feed objects, which know
about what their mime type is, title, location, all that jazz.
I changed the FeedList class so it handles the new Feed objects
instead of the old array of data.
I changed all the actions that show feeds (I think...) so that they
now use getFeeds() for all their feed needs.
Since plugins may define custom actions, we shouldn't require that
there be a file in our actions/ subdir for every action. So, I changed
the (admittedly hackish) auto-loading code in index.php so it instead
checks whether a class exists with the expected name. This, in turn,
uses the increasingly hacking __autoload() function, which I changed
to auto-load stuff named "BlahblahAction" from the actions subdir if
available.
Added two exception classes: one for client errors (= user can fix) and
one for server errors (only admin or coder can fix). The web entry point
now tries to catch exceptions and show them in the browser. The main
code for showing errors in Action class now throws an exception and lets
top-level handle it.
