Jim Fulton wrote:
> but I would hope that we wouldn't contradict the decision, made some time
> ago that Zope, unless qualified (as in "Zope Community" or "Zope
> Toolkit"), refers to Zope 2. If we did, it would have been because we
> were speaking informally.
>> I'd like to pursue this by starting a discussion about Zope's functional
>> areas among the developer community and hope to come up with a number of
>> commonly agreed-upon items. Wherever it matters, I suggest limiting
>> ourselves to discussing the ZTK in order to keep things focussed.
> I think you mean "ZTK" functional areas. Or, perhaps better, Zope
> Community functional areas.
I'd say let's talk about Zope Community functional areas as long
as we're trying to identify what's involved in web programming
and what, therefore, are the problems a community of web
developers is being faced with. I think, however, that the Zope
toolkit is what will profit most from an understanding of
functional areas, so let's switch to talking about the ZTK's
functional areas when the discussion becomes ZTK specific.
>> the project would be the possibility to organise the large and grown set
>> of individual packages that make up Zope's code.
> OK, so a benefit is to organize packages. I guess I can see that. So, a
> documentation exercise. Perhaps this would be better left to people
> writing documentation.
> I have a feeling that some people want to organize community development
> efforts around these areas, although I don't think you're saying that,
> although perhaps you hint at that in your summary.
Obviously I didn't clearly enough say so, but I do think that
organising development and communication are the primary benefits
of identifying functional areas, but OTOH I wouldn't dismiss the
aspect of organising (and better documenting) the code itself as
a lesser task, even though I do understand that it may not be
everybody's first concern (obviously not yours and not mine, either.
>> - client-side programming framework (no good solution so far, people use
> Huh? There are many good client side development libraries. There isn't
> think Tim made a mistake when he included TOOWTDI in the Zen of Python).
But while there are good client-side frameworks, integrating them
with the server side is still something I'd consider a
functionality of the server framework or application, which is
why I'm inclined to count client-side programming among the
(I'd like to suggest, however, discussing the Zope community's or
the toolkit's answer to that in a separate thread so this one can stay
focussed on identifying the functional areas in the first place.)
> - integrating with form-generation libraries based on zope.schema,
> - transactional REST interfaces, and
> - perhaps more direct ZODB data access <shrug>.
Would you agree that these items define a functional area?
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -