[Zope-dev] Functional areas of Zope
Jim Fulton
jim at zope.com
Mon Oct 18 10:36:27 EDT 2010
On Mon, Oct 18, 2010 at 8:29 AM, Laurence Rowe <l at lrowe.co.uk> wrote:
> On 18 October 2010 12:51, Thomas Lotze <thomas at 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
More information about the Zope-Dev
mailing list