Mario Ruggier wrote:

> On Aug 18, 2004, at 3:12 PM, Graham Fawcett wrote:
>
>> I'd love to see something that was component-oriented enough so that I
>> could, for example, decide whether to use a relational database, or
>> ZODB, or just a bunch of text files to handle persistence. Something
>> that works "out of the box" with only Quixote as a requirement (or at
>> least only depended on third-party Python packages, but not on other
>> installed software) would be tremendously helpful.
>
> I was actually thinking more about the other end... the front-end that
> is. Components that can be easily plugged into a site, and that can be
> both page-level, and sub-page-level (boxes on a page...), or a mixture
> of both... e.g. forums, tracker, news, subscriptions/newsletters, ...
> another cms-building framework! This of course means a common auth
> interface, common handling of privileges and roles, and so on... do not
> think that that is what the scope of quixote is, or will ever be... but,
> having such a component web framework defined and implemented in the
> quixote philosophy of explicitness and simplicity would certainly save a
> _lot_ of trouble... while probably making this world a significantly
> better place ;-!

disclaimer: IANATFD (I am not a talented framework designer)

A good idea, and those kind of components would be useful if they can be
generalized. But generalizing them means that you need to be able to separate
out any back-end issues, most notably persistence. Presumably, if you want to
have a discussion-forum widget display on a Web page, you need a
DiscussionForum instance representing the data structure, and encapsulating any
details about how/where the instance is stored. Since you're wiring together
components that are potentially from many different developers, some method of
customizing the persistence of each type of package is also important.
Otherwise, you'll end up with a DiscussionForum that talks SQL and an
IssueTracker that expects ZODB... you get the idea.

(This applies whether you are creating sub-page "components" or multi-page
mini-application "components", though the integration issues are different. One
is about components that are instantiated and rendered during the run of the
application; the other is about the components that were used to construct the
application itself. Maybe it's all the same: I imagine, generally speaking,
that the former always depends on the latter.)

If someone wrote the DiscussionForum package, and their implementation used a
MySQL database, but they had broken their implementation up into components
separated by well-defined interfaces, then I could "unplug" the MySQL-specific
stuff, and replace it with something else that implemented the same interface;
and Everything Should Just Work. It's rarely that easy, of course; but without
those interfaces in place, it's a heck of a lot harder, and would lead me into
a morass of custom patches that I would need to keep track of.

If you buy the story so far, then we also need a way of selecting which
components to use (the SQLDiscussionStorage or the ZODBDiscussionStorage). It
would be nice to have some conventions on how to do this... Martin Fowler's
writing on inversion-of-control give a couple ways that it's done in the wild.
Regardless, having the interfaces in the first place is the key step.

I would love to see a component-oriented framework that worked well with
Quixote *and* was as elegant and as simple as Quixote, staying out of my way so
I can get work done, but also letting me reuse components that others have
written (or that I've written for other projects). A way of declaring common
services (like a user directory/authentication service) would be helpful too.
But I don't want Zope3 or PEAK, just a gentlemen's agreement or two and some
good component design.

Equally importantly, I would love to see such a framework that a plurality of
Quixote developers could agree upon, so that we could actually get down to
building reusable parts.

....but this could all be a pipe dream. I get excited about component-oriented
development sometimes, and all I end up with at the end of the day is a big
mess. Perhaps I'm a bad designer, and should stick to hammering out code...

I hope we are all agreed that none of this belongs *within* Quixote. Don't mess
with the Q, it's just the right size! ;-)

Just my 20 cents,

-- Graham