|
(also posted to pyds-dev) This might seem a little controversial, but I'm thinking of making rendering as completely distinct from editing as possible. I can run CGI scripts at my upstream site. Rather than render locally and FTP or XML-RPC upload every page, which can get quite bulky if posts are in multiple categories, I'd prefer to upload changed database entries and have the pages rendered upstream. This plays well into the Funky Caching idea, where pages are rendered on the fly by a 404 handler. If you know a page is out of date, just delete it; if anyone wants it, it'll come back later. Better yet, one could also run PyDS in some hypothetical CGI-based mode (my host doesn't permit persistent processes) to make posts from computers that can't contact the PyDS server over the network. This ties in nicely with my database access refactoring idea, and with my (as yet undisclosed) idea for adding support for rendering via ZPT. It sounds pretty safe to create the schema database, add a tool to synchronize database entries based on those schema, add a way for tools to customise rendering based on that (which'd work either locally or remotely)... and all without disrupting the core too much. Cool. |
|
After waking up at 3am to kill a mosquito, I couldn't get to sleep, and for some reason ended up thinking more about how to work around some of Metakit's limitations in PyDS. Top of the list was a module used to mediate all access to databases. That module would cache storage references so that multiple tool modules could access other tools' databases safely. [Opening a database twice just doesn't work -- a new record or property defined by one instance can't be accessed via the other, and I suspect data corruption wouldn't be far away if you made changes on both.] The module would also maintain a schema database, of known and fixed layout, that stored information on all the defined properties of the other databases. That'd work around the "need at least one valid property name to find out the other properties" problem. The final realisation of the night, just before I drifted off, was that a nice way to let tools define attributes on other tools' databases was to take a leaf out of XML namespaces. Inside Metakit, the properties would be (say) .id, .title etc for the WeblogTool, and .radio__id for the Radio ID property defined by the RadioMigrationTool. As accessed by the rest of PyDS, it'd be .id, .title, and .radio.id. So long as we kept tool names from clashing with property names, I think we'd be safe, and that's something the schema database could greatly help with. Having safely given tools access to other tools' data, all we need is a few callbacks in various tools (particularly the WeblogTool, but also others) so that other tools can hook the edit form, RSS generation, HTML generation, and other bits. That's later, though. :) |
