Hi all, at the Zope summit in September, we were talking about what Zope actually is or should be and how to define the goal of the Zope project. This led to the idea of identifying the functional areas of Zope. 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. As functional areas (for some examples, see below), we consider diverse, broadly defined tasks and problems that a web developer is being faced with, and that a web framework ought to have an answer for. We hope to be able to define better what Zope is and is not and how it compares to other web frameworks by starting from a set of functional areas and trying to state Zope's answer to each of them. Another benefit from having a grip on functional areas of Zope the project would be the possibility to organise the large and grown set of individual packages that make up Zope's code. To get the discussion started, I'll give a few random examples of functional areas that we thought of immediately: - software architecture (interfaces, components) - data persistence (ZODB) - URL resolution (object traversal) - form generation (form libs for HTML forms, other possibilities?) - resource handling (CSS, Javascript delivery) - client-side programming framework (no good solution so far, people use all sorts of Javascript technologies and programming styles) I hope for the discussion to produce a list of functional areas that most developers agree upon, maybe further areas that need more consideration, and possibly even some clues about Zope's answers to the challenges of each functional area. Thank you very much for your participation. -- Thomas
On 18 October 2010 12:51, Thomas Lotze <thomas@thomas-lotze.de> wrote:
Hi all,
at the Zope summit in September, we were talking about what Zope actually is or should be and how to define the goal of the Zope project. This led to the idea of identifying the functional areas of Zope. 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.
As functional areas (for some examples, see below), we consider diverse, broadly defined tasks and problems that a web developer is being faced with, and that a web framework ought to have an answer for. We hope to be able to define better what Zope is and is not and how it compares to other web frameworks by starting from a set of functional areas and trying to state Zope's answer to each of them.
Another benefit from having a grip on functional areas of Zope the project would be the possibility to organise the large and grown set of individual packages that make up Zope's code.
To get the discussion started, I'll give a few random examples of functional areas that we thought of immediately:
- software architecture (interfaces, components) - data persistence (ZODB) - URL resolution (object traversal) - form generation (form libs for HTML forms, other possibilities?) - resource handling (CSS, Javascript delivery) - client-side programming framework (no good solution so far, people use all sorts of Javascript technologies and programming styles)
I would say that javascript and client side programming frameworks are out of scope for Zope the project. There are plenty of existing client side frameworks (jquery, YUI, etc.) with varying degrees of weight and functionality. We don't want to build another. Zope components may need to implement some rich functionality (form widgets for instance), in which case it may be worthwhile picking a particular javascript framework to use (Plone uses jquery). We also want to make it easy to communicate between client side javascript and server side python via JSON (bobo implmented some json help classes IIRC). Laurence
On Mon, Oct 18, 2010 at 8:29 AM, Laurence Rowe <l@lrowe.co.uk> wrote:
On 18 October 2010 12:51, Thomas Lotze <thomas@thomas-lotze.de> wrote:
...
I would say that javascript and client side programming frameworks are out of scope for Zope the project. There are plenty of existing client side frameworks (jquery, YUI, etc.) with varying degrees of weight and functionality. We don't want to build another.
I agree. The only exception would be if someone came up with something so innovative that we chose to embrace it. I think that the focus of the community should be better leveraging existing libraries.
Zope components may need to implement some rich functionality (form widgets for instance), in which case it may be worthwhile picking a particular javascript framework to use (Plone uses jquery).
I think it would be counter productive to pick a JS library. We've done some work at ZC on abstracting the JS interface for form generation. See zc.ajax for an early example. (Unfortunately, due to an internal misscommunication here at ZC, that project got forked and recent work has been in our internal repo. We need to move that to the zope repo) The basic idea is that server side "widgets" generate high-level json specifications that can be implemented for different js libraries. A number of people have done work in this area. We should find some forum to compare notes.
We also want to make it easy to communicate between client side javascript and server side python via JSON (bobo implmented some json help classes IIRC).
So does zc.ajax (and our unfortunately internal zc.ajaxform). These fit better with zope.publisher, fwiw. I'm sure there are other examples of this in the zope ecosystem. Jim -- Jim Fulton
First of all, please excuse the long time without a reply - I spent the last two weeks sick. Jim Fulton wrote:
On Mon, Oct 18, 2010 at 8:29 AM, Laurence Rowe <l@lrowe.co.uk> wrote:
I would say that javascript and client side programming frameworks are out of scope for Zope the project. There are plenty of existing client side frameworks (jquery, YUI, etc.) with varying degrees of weight and functionality. We don't want to build another.
I agree. The only exception would be if someone came up with something so innovative that we chose to embrace it. I think that the focus of the community should be better leveraging existing libraries.
I agree with that as well. In fact, I wasn't saying that Zope (the community) should invent a client-side framework of its own, but was rather mentioning client-side programming as one example of a problem domain that web programming nowadays includes and which I suggest the Zope community should have at least some answer to, making "client-side programming" one functional area of Zope in my opinion. That answer may of course be something that involves deploying one or more existing Javascript framework(s). To stay focussed on defining functional areas, however, let me suggest focussing this thread on the question whether we want to consider client-side programming a functional area of Zope in the first place, and maybe opening a new thread for discussing possible answers the Zope community might come up with.
A number of people have done work in this area. We should find some forum to compare notes.
We also want to make it easy to communicate between client side javascript and server side python via JSON (bobo implmented some json help classes IIRC).
So does zc.ajax (and our unfortunately internal zc.ajaxform). These fit better with zope.publisher, fwiw. I'm sure there are other examples of this in the zope ecosystem.
IMO, this speaks for considering client-side programming a functional area of Zope and at the same time, indicates how identifying such areas enables us to better understand and coordinate development efforts and communication. -- Thomas
On Mon, Oct 18, 2010 at 7:51 AM, Thomas Lotze <thomas@thomas-lotze.de> wrote:
Hi all,
at the Zope summit in September, we were talking about what Zope actually is or should be and how to define the goal of the Zope project. This led to the idea of identifying the functional areas of Zope.
I don't think that's quite right. I don't remember exactly what we said, 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.
As functional areas (for some examples, see below), we consider diverse, broadly defined tasks and problems that a web developer is being faced with, and that a web framework ought to have an answer for. We hope to be able to define better what Zope is and is not and how it compares to other web frameworks by starting from a set of functional areas and trying to state Zope's answer to each of them.
My opinion, stated at the DZUG, is that Zope is *not* a framework. I think treating it as a framework was an early mistake that has haunted us for years. The ZTK (which we should have had from the beginning) is a collection of frameworks that support Zope the application.
Another benefit from having a grip on functional areas of Zope
I'm sorry did you mention benefits above? I dont see them.
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. ...
- client-side programming framework (no good solution so far, people use all sorts of Javascript technologies and programming styles)
Huh? There are many good client side development libraries. There isn't one obviously "right" javascript library, but there shouldn't be. (I think Tim made a mistake when he included TOOWTDI in the Zen of Python). I'm not going to fault someone for trying to come up with something newer and better, but I don't think it should be a Zope functional area. OTOH, I do agree with Lawrence that there's a lot of value in collaborating on how to integrate existing JS frameworks with the Zope server-side frameworks. Of particular interest to me are: - integrating with form-generation libraries based on zope.schema, - transactional REST interfaces, and - perhaps more direct ZODB data access <shrug>.
I hope for the discussion to produce a list of functional areas that most developers agree upon, maybe further areas that need more consideration, and possibly even some clues about Zope's answers to the challenges of each functional area.
If nothing else, I think the discussion will be valuable.
Thank you very much for your participation.
Thanks for spuring discussion. Jim -- Jim Fulton
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.
Agreed.
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 all sorts of Javascript technologies and programming styles)
Huh? There are many good client side development libraries. There isn't one obviously "right" javascript library, but there shouldn't be. (I 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 functional areas. (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? -- Thomas
Thomas Lotze wrote:
To get the discussion started, I'll give a few random examples of functional areas that we thought of immediately:
- software architecture (interfaces, components) - data persistence (ZODB) - URL resolution (object traversal) - form generation (form libs for HTML forms, other possibilities?) - resource handling (CSS, Javascript delivery) - client-side programming framework
Let me add a few more that Wolfgang and I have been thinking about in the meantime, hoping that they provoke more discussion and maybe give a better idea of what I'm trying to talk about: - general templating to generate HTML & friends - security: authentication, authorisation - logging, error handling - providing web services - i18n - caching - sessions - testing -- Thomas
participants (3)
-
Jim Fulton -
Laurence Rowe -
Thomas Lotze