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

[Craeg Strong]

Martijn Faassen wrote:
> cstrong at arielpartners.com wrote:
>> Yes, ... I want CRUD.
>
> 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.
Thanks, I will try it this weekend!
> Let me sketch out my ideas about CRUD.
<snip/> <paraphrase/>
>
> 1) CRUD RAD: provide infrastructure to make it really easy to make 
> CRUD UIs for applications.
>
> 2) introspector: provide out of the box stuff so a developer can 
> browse the ZODB, possibly also tweak things
>
> 3) "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.
>
> Martijn
I am only interested in #2 at the moment, but I certainly see the value 
in all three.    I would like to help bring up #2 to a higher level of 
capability.
I would like to see full capability for editing/replacing/creating new 
objects, where some of that functionality may be provided via escaping to
an interactive session, for example a little TTW interface to a python 
interpreter.  
The ability to dynamically/interactively fix "broken" objects in my app 
in ZODB would be IMO a major use case for this facility.

Basically, I want the same level of power and scope that someone using a 
SQL editor (and logged in as schema owner) enjoys over his database,
or someone who is using IE Script Editor or Firebug enjoys over all the 
javascript running in a web page.  They both have the ability to
drop into an interactive session at any time and make essentially 
arbitrary changes. 

The fact that I can't easily do that on ZODB makes it more scary to me.  
Data corruption, schema changes, data migration, etc-- those are facts 
of life in a rapid-development shop, and those darn relational database 
guys still have it all over us in that department (at least it seems so, 
from my vantage point).

Again, it goes without saying that all of this stuff is for 
administrator/developer only, and would represent a horrendous security 
hole if it wasn't
hidden away with all the other developer tricks....

Does this make sense?

--Craeg