[Grok-dev] Re: browsing and modifying persistent objects in zodb

[Martijn Faassen]

Hey there,

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,
> etc.
> 
> 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 
container browser.

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 
for applications.

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 
construction.

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.

Regards,

Martijn