[Grok-dev] Re: browsing and modifying persistent objects in zodb
faassen at startifact.com
Sat Jun 21 08:03:54 EDT 2008
cstrong at arielpartners.com wrote:
> Yes, that is exactly what I mean, I want CRUD. Such a facility doesn't
> have to be beautiful, just functional.
> I would love to see a simple version and then start enhancing it,
> gradually adding things like XHR/AJAX for painless updates, pagination,
> I bet if even a simple/primitive version of this were to land in an
> official Grok release, people would start to use it and send suggestions
> and enhancements (I, for one).
> It would be a nice easy place to contribute because it is not part of the
> core grok engine but rather just a bundled application/control panel.
Note to start that Grok *does* already have a primitive object browser
built in. Have you tried the introspector functionality? You can find
out a lot about objects, but I think it should look more like a
Let me sketch out my ideas about CRUD.
I think there are some approaches to CRUD:
CRUD RAD: provide infrastructure to make it really easy to make CRUD UIs
introspector: provide out of the box stuff so a developer can browse the
ZODB, possibly also tweak things
"admin UI": provide out of the box stuff so that an end-user can at
least do some data editing with a default CRUD interface.
All these I think are valuable. Django, I take it, also has an "admin
UI", but not really an introspector, and I don't think they have RAD
tools for CRUD either. The Zope 2 ZMI was also hovering somewhere
between an introspector and an admin UI, and over time it became more of
an introspector, geared towards developers.
With Grok, we currently have the introspector effort, with 'tweaking
things' still of lower priority.
The danger of an admin UI is that people will want to extend it into
more full CMS UIs. I think that is what people tried to do with the ZMI,
and I don't think that's really a good idea. We should be really careful
about the scope of any admin UI, especially in the beginning.
I think the true power of Grok will show in RAD CRUD tools. We can write
some very high level components that make it easy and fast to build a
CRUD interface for your own application. This is what I and Joachim were
experimenting with, but we didn't get very far yet.
Concerning user interfaces for Grok, I think we should aim for
detachable user interfaces. Uli is going to start with grokui.admin,
which contains what admin UI we have (installing applications, server
management, etc) and, for now at least, is also going to house the new
introspector. It's being taken out of the grok core into its own
package, but, for now, we'll also turn around and make the grok core
rely on this. In the future we need deployment scenarios where we can
choose to not install this stuff at all, though.
I think it makes sense to start working on other things in the grokui
space. We *must* keep in mind though that what we're doing here is
building convenience tools primarily aimed at developers, and not so
much at end users. We must also realize that we're not offering some
kind of general framework to build CMS-style applications with this
stuff. I don't want to absolutely discount such developments in the
future, but I think we should clearly focus away from this and just aim
at introspection and tweaking tools in the beginning, aimed at
developers, not pluggable user interfaces for general application
Besides this, I think there is room for a megrok.crud effort, which
should aim at making it really easy to create typical CRUD style user
interfaces with Grok.
More information about the Grok-dev