durusmail: quixote-users: is anyone working ona task list, bug list, issue tracking type utility
is anyone working ona task list, bug list, issue tracking type utility
2004-08-17
2004-08-17
2004-08-18
is anyone working ona task list, bug list, issue tracking type utility
2004-08-18
is anyone working ona task list, bug list, issue tracking type utility
2004-08-18
Re: is anyone working ona task list, bug list, issue tracking type utility
2004-08-19
Re: is anyone working ona task list, bug list, issue tracking type utility
2004-08-19
Re: is anyone working ona task list, bug list, issue tracking type utility
2004-08-19
is anyone working ona task list, bug list, issue tracking type utility
2004-08-18
2004-08-18
is anyone working ona task list, bug list, issue tracking type utility
2004-08-18
2004-08-20
2004-08-20
[slightly OT] Component frameworks and Inversion of Control Pattern
2004-08-23
Re: [slightly OT] Component frameworks and Inversion of Control Pattern
2004-08-24
2004-08-24
Re: [slightly OT] Component frameworks and Inversion of Control Pattern
Re: [slightly OT] Component frameworks and Inversion of Control Pattern
2004-08-24
Re: [slightly OT] Component frameworks and Inversion of Control Pattern
Re: [slightly OT] Component frameworks and Inversion of Control Pattern
Re: [slightly OT] Component frameworks and Inversion of Control Pattern
2004-08-25
Re: [slightly OT] Component frameworks and Inversion of Control Pattern
2004-08-25
Re: [slightly OT] Component frameworks and Inversion of Control Pattern
is anyone working ona task list, bug list, issue tracking type utility
Shalabh Chaturvedi
2004-08-18
>> On Aug 18, 2004, at 12:17 AM, Simon Cusack wrote:
>>> Maybe we should organise a plug in architecture for commonly used
website components like this would be helpful.  Anybody thought of
this?

> Mario Ruggier wrote:
>> Every web framework has dreamed of this sooner than later... I would
certainly love to see a quixotic component spec, and if there'd be
such a thing I'd be happy to program against (for ;) it.

Graham Fawcett wrote:
>
> I'd join in too.
>
> 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.
>
> -- Graham

Now that you mention this, I have been working on such a beast :) In  fact
being able to switch the underlying data source as long as the  schema
remains the same is also one of the goals. An object-relational  wrapper
has already been implemented. Currently supporting PostgreSQL  and
Firefox.

Also, there is the concept of a 'registry' which is just a hierarchial
arrangement of objects (accessible simply by attribute access a.b.c).  The
registry is meant for connecting objects to each other (so they use  a
specified application or data source etc.) and the published site root  is
a location in the regitry. This means pre-written applications can be
deployed at any url you choose at deployment time by means of a
configuration file.

One important principle I (try to) follow is to require minimal APIs and
definitions. For example there is no explicit schema (re)definition when
you use a relational database - unlike most other OR mappers. There is  no
interface definition either. IMO the whole point of using Python is  to
achive loose component interaction based on protocol, not interface. Just
write the classes, connect them together (using the registry), *test it*
and ship it!

The registry and data layer are actually working and I even have
applications running on it. However packaging issues remain. If there is
interest, I'd be happy to post an unfinished handbook which explains the
above in a lot more detail.

Cheers,
Shalabh






reply