Yes this is what I was looking for and somewhat expecting. I can
understand the challenge in getting ZClass, Py/Perl Script, "composite
components" done right. In fact to me they could easily make things more
complex. Potentially more complex process and more complex machinery to
handle it. I would definitely be for a simpler model of components which
are just as describe .py files and an interface.
I read somewhere that doing components right is/can be hard. The author
wrote that component creation is done by the few for the many. There
will be fewer component authors and more component users and
integrators. I agree with his assessment.
I think what will make it easier for component authors will be well a
defined API. This appears to me what y'all are doing. If I understand
Michel Pelletier wrote:
> On Tue, 27 Feb 2001, Jimmie Houchin wrote:
> > While reading the Zope Development Roadmap about components I had a
> > question.
> > It says:
> > """Components will be edited via the filesystem as .py files. Components
> > will probably be checked into and out of Zope via a CVS like facility.
> > Components can be tested locally without checking them into Zope."""
> > What does this say about developing components with Py/Perl Scripts?
> > It looks to be closer to the current Python Products.
> Yes. We have thought a bit about "composite components" and "persistent
> modules" and stuff like that, but we only went so far into elaboration
> when we realized that it required lots, and lots of thought and effort.
> The current component effort is much simpler, a component is: an object
> with an interface. If this is a ZClass with Perl-based script methods,
> then so be it, but we haven't thought far enough into what ZClasses really
> are to start thinking about giving them interfaces.
> Is this sort of what you're asking?
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -