[Grok-dev] mass ping - grokui.admin

[Uli Fouquet]

Hi there,

Martijn Faassen wrote:

> Kathy Manwaring wrote:
> > Well, as a newby, I feel guilty about disagreeing with Martijn,
> 
> There's no need to feel that way at all. Please continue to point out 
> where you disagree with us.
> 
> > but I HAVE
> > used the introspector - particularly recently. 

Cool, at least one person did :-)

> I think that means we weigh bringing back the introspector a bit more 
> heavily. I still think we shouldn't let it slow us down if it's 
> difficult, but I also think that if someone seriously studied 
> zope.app.apidoc on which the introspector is built, we could replace it 
> without reintroducing the dependencies we're trying to get rid of.
> 
> > However, I am not sure that
> > it is currently (Grok 1.0) working as expected, as it only gives me access
> > to the object as
> > Thomas, David  "{'zope.app.dublincore.ZopeDublinCore':
> > <zope.dublincore.annotatableadapter.ZDCAnnotationData object at
> > 0x03A68270>}"
> > when it is actually a 'Person' object in my schema - 
> 
> I'm not sure what's going on here. Uli, would you be able to hazard a guess?

My guess is that there is a faulty traverser at work that does not
properly examine objects and then erraneous returns ZDC adapters, where
it is not necessary (shouldn't happen at all).

This is not difficult to fix, but in the long run we might want
something more Pythonic, which requires a more or less complete rewrite.
I am undecided whether we should fix such failures.

As the introspector stuff was already kicked from grokui.admin (most
people can only see it, as grok includes very old versions of it in .cfg
file), I guess there is not much point in discussing whether to keep or
to kick it. It already happend months ago.

But as Soulheil requested a mass ping, I might backping some silly
bits: 

zope.app.apidoc is a monster of functionality (and a monster of
dependencies, of course). In fact it provides at least three different
kinds of info:

* Interface infos

* Object infos (i.e. of persistent ZODB objects)

* Code infos

Instead of building one huge browse-it-all package (like
grokui.introspector still tries), it might be cleaner to split these
kinds of info into three packages (or at least subpackages):

* A ZODB browser (infos about object instances stored in ZODB)

* A code browser (present sources, .rst and .txt files)

* A 'configuration' browser (presents interfaces and related meta infos,
    like views/skins/adapters/utilities registered for some object).

All these components have to interact with each other to give a more or
less usable UI. These links might be provided by the base package
(grokui.base), if it allows a pluggable mechanism, so that a ZODB
browser can link to the source-code file of an implementation of a class
if it want to, etc.

Furthermore zope.app.apidoc provides techniques to write your own
documentation for components (grokui.admin does this too, in a more
simple manner), which seems to be used hardly. So we might consider to
drop support for writing 'books'.

I currently use apidoc.zope.org from time to time, but I often find it
difficult to get the information there, I really want. Hard to say what
exactly is wrong there. It might be caused by my dumbness, but I would
not oppose ideas how to organize info presentation in a manner more
suitable (intuitive) for dumb guys like me.

Another thing I could not find in the discussion yet: the 'server'
section of grokui.admin. It also pulls in some dependencies. Maybe we
should kick that too?

> > but I am not
> > confident enough with Grok/Zope to say this is an issue with the
> > introspector, it may be something that I'm not doing quite right. (My view
> > of the object shows all the Person information, so I expected to see it
> > via the object browser).

This is definitely an introspector bug. I'll fix it in the next days.

BTW: grokproject 1.0.1 was released today and should fix the nasty
permission problem ('zope.Anybody' vs. 'zope.Everybody'). Please tell if
you discover problems with it (apart from Grok 1.0 not runnig with
Python 2.6, this was reported already).

Best regards,

-- 
Uli

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://mail.zope.org/pipermail/grok-dev/attachments/20100124/f65baf9b/attachment.bin