Mailing List Archive

Dethe Elza wrote:
> Relating to recent discussion of whether arbitrary Zope objects can be
> represented meaningfully in XML, there are a few articles and scripts by
> David Mertz that are interesting in the same vein:
[snip]

Interesting. I think I had seen one or two of these before, but I hadn't
thought about them yet in the light of Zope and XPath.

The way to have a simplified more pythonic access to an underlying
DOM is neat. We should consider offering such access to DOMs in
Zope as well, if we can work out the security implications.

> Since ordinary Python objects can be treated as XML, it seems to me that
> it shouldn't be hard to treat random Zope objects as DOM in ZDOM, which
> is where I was coming from when I suggested that we have a default
> representation for all objects and only use a registry for objects which
> need (or want) to be treated specially. If there has to be a registry
> entry describing how to handle every Zope object in use, well, that just
> doesn't seem realistic or feasible.

The problem is that David Mertz' XML pickle strategy pickles object
attributes, but doesn't do much about methods. The equivalent would be
exposing to the DOM (as attributes or perhaps as sub element nodes or
a mixture) the attributes of some persistent Zope object.

That's not very useful in the Zope content for a number of reasons:

* security; the innards shouldn't be exposed like that generally.
Normally you get to this by using methods which do security checks,
etc.

* semantics; the innards don't mean much to Zope users; we're far more
used to the Zope APIs, not to the way Zope actually stores things.
Do you know how ObjectManager stores its contents exactly? I don't,
I do know I can use objectIds() and objectValues() and such to
get a list of what's there, though.

What needs to happen, and why I think a registry of adapters is unavoidable,
is that we expose what's accessible through object's APIs to the DOM somehow.
So, an objectValues() would turn into a list of childNodes. Properties
and other attributes can often become attribute nodes. Text contained by
some object can become a text node. The representation to the DOM should:

* follow security; go through the Zope APIs and check whether this
user can do this.

* have a comprehensible semantics. The represenation really needs to
be human readable and should just not be a simple reflection of what
can be pickled.

I do think we can get quite a long way by providing some standard adapters
for a set of core components. Even doing Folders with properties and
perhaps a listing of contents can be helpful already, after all. I'd
consider exposing the innards of objects to the DOM as not very useful,
even if you can get the security details worked out.

Eventually there should be an easy way for product developers to expose
their stuff to the DOM. There should be product guidelines so product
authors can write something up themselves. There should also be a set of
standard adapters that product authors can choose to reuse, so that they
can get this done relatively quickly.

Perhaps there is a way to translate common APIs to DOM access almost
automatically, with only a few hints here and there from a developer.
Ideas?

Regards,

Martijn

Martijn Faassen wrote:


> The problem is that David Mertz' XML pickle strategy pickles object
> attributes, but doesn't do much about methods. The equivalent would be
> exposing to the DOM (as attributes or perhaps as sub element nodes or
> a mixture) the attributes of some persistent Zope object.

<further reasons snipped>

I didn't mean to imply we could use Mertz's classes directly, after all
they are focussed on XML as text file and we are focussed as XML as DOM
API (with the additional considerations of Zope security and semantics,
etc). Only that a similar approach would be worth considering, or if
not worth considering, at least gives insight into my earlier suggestions.


> I do think we can get quite a long way by providing some standard adapters
> for a set of core components. Even doing Folders with properties and
> perhaps a listing of contents can be helpful already, after all. I'd
> consider exposing the innards of objects to the DOM as not very useful,
> even if you can get the security details worked out.


Yes, I think listing folders and their contents would be a helpful first
step. Actually, listing *folderish* and their contents would be even
better.

> Eventually there should be an easy way for product developers to expose
> their stuff to the DOM. There should be product guidelines so product
> authors can write something up themselves. There should also be a set of
> standard adapters that product authors can choose to reuse, so that they
> can get this done relatively quickly.


Product guidelines? Standard adapters? That's crazy talk! If we did
that then *anybody* could use it. I think we should follow the CMF
guidelines and make everyone read the implementation code from CVS.
(Sorry, been struggling with underdocumented Zope features quite a lot
lately, I'm not usually given to fits of irony.)

> Perhaps there is a way to translate common APIs to DOM access almost
> automatically, with only a few hints here and there from a developer.
> Ideas?


I'm afraid my ideas are limited to, "I'm sure there's a way, but my
understanding of the underbelly of Zope is too limited to know what that
way is." Which isn't really helpful, so I withdraw it.

--Dethe

--

Dethe Elza (delza@burningtiger.com)
Chief Mad Scientist
Burning Tiger Technologies (http://burningtiger.com)
Living Code Weblog (http://livingcode.ca)

On Fri, 2001-10-26 at 15:49, Dethe Elza wrote:
>
> I'm afraid my ideas are limited to, "I'm sure there's a way, but my
> understanding of the underbelly of Zope is too limited to know what that
> way is." Which isn't really helpful, so I withdraw it.

Don't feel bad, I've encountered that particular situation so many times
in the past that I routinely self-censor these days.

Of course, sometimes this leads to long term frustration. The ZMI still
doesn't have a built-in way of representing many-to-many relationships
between objects, for instance, and I first started a discussion about
that over two years ago. The most recent time I participated in that
conversation, it seemed like it devolved to "oh, we'll just use XPath
when Zope's XML support incldes it".

<grumble>

Michael Bernstein.

Michael R. Bernstein wrote:
> On Fri, 2001-10-26 at 15:49, Dethe Elza wrote:
> >
> > I'm afraid my ideas are limited to, "I'm sure there's a way, but my
> > understanding of the underbelly of Zope is too limited to know what that
> > way is." Which isn't really helpful, so I withdraw it.
>
> Don't feel bad, I've encountered that particular situation so many times
> in the past that I routinely self-censor these days.

I didn't think Dethe's ideas were unhelpful at all though; I think the idea of
doing an automatic translation of Zope API to DOM representation is interesting.
We need to flesh this out further and I'm quite interested in seeing more
Stuff on this, myself.

I don't think this is so much a Zope problem in itself; it's more of a python
problem, though the security part and the ZODB part do come in.

We have a bunch of Python objects with some API consisting of methods (perhaps
attributes, such as id, but that's deprecated). The goal here would be to
have a system which can mostly automatically somehow map this onto a
human-sensible DOM interface.

We need some examples of what such a mapping looks like, to analyze the story
further. To make it easy we can simply write out the XML that the DOM would
present itself, so we could say something like:

objectIds()

<objectIds>
<entry>foo</entry>
<entry>bar</entry>
<entry>baz</entry>
</objectIds>

or more complex:

<objectValues>
<Folder zope_id="foo">...</folder>
<DTMLMethod zope_id="bar">...</DTMLMethod>
</objectValues>

Perhaps. It would then be possible to do XPath queries. ZDOM manipulation support
sounds far harder to make automatic than just ZDOM readonly support, by the way,
but I think there's some hope to make readonly support more automatic.

So, this discussion in my opinion is fruitful. Even if the idea is finally
rejected we will have learned something.

> Of course, sometimes this leads to long term frustration. The ZMI still
> doesn't have a built-in way of representing many-to-many relationships
> between objects, for instance, and I first started a discussion about
> that over two years ago. The most recent time I participated in that
> conversation, it seemed like it devolved to "oh, we'll just use XPath
> when Zope's XML support incldes it".
>
> <grumble>

I hope I didn't participate in that discussion. :)

Zope-XML seems to be having a very very difficult birth.

Anyway, I'm sorry if I gave the impression to people that their ideas make
no sense and that they know nothing. That I find objections doesn't mean
I want to reject ideas outright or something; if you go on a bit then we
can frequently get somewhere. I tend to argue (too much) to get my point across,
but I'm all for cooperation and consensus overall.

Perhaps it's a hacker culture type thing; blunt objection doesn't mean the
idea is necessarily rejected, just not perfect yet.

Regards,

Martijn

Martijn Faassen <faassen@vet.uu.nl> writes:

> The problem is that David Mertz' XML pickle strategy pickles object
> attributes, but doesn't do much about methods. The equivalent would be
> exposing to the DOM (as attributes or perhaps as sub element nodes or
> a mixture) the attributes of some persistent Zope object.
>
> That's not very useful in the Zope content for a number of reasons:
>
> * security; the innards shouldn't be exposed like that generally.
> Normally you get to this by using methods which do security checks,
> etc.

Well, I never thought that ZDOM would interact with the security
mechanism in a DOMish way. A DOM method such as attributes() would
return whatever the security context allowed, just like any other
method called with a security context, but the restricting wouldn't
have anything to do with how the DOM calls are invoked.

In other words, a Python call of a ZDOM method would be as
unrestricted as any other Python access of the DB, while a
hypothetical XPath access of ZDOM invoked via a web interface would
only see what was allowed by that interface's security context. But
that security isn't expressed meaningfully by the DOM, it's expressed
by the fact that these are still Zope objects - that is, a ZDOM object
might have an ac_permissions DOM attribute, but security isn't handled
by accessing that interface thru the DOM, and the custom adapter (like
mentioned below) might not even expose it.

IOW, security doesn't change. I never thought too hard about it,
though, is this a naive?

> What needs to happen, and why I think a registry of adapters is unavoidable,
> is that we expose what's accessible through object's APIs to the DOM somehow.
> So, an objectValues() would turn into a list of childNodes. Properties
> and other attributes can often become attribute nodes. Text contained by
> some object can become a text node. The representation to the DOM should:

Adapters are unavoidable because the DOM is document-centric.
Otherwise the only way to look at the ZODB would be as one large
document rooted at Zope.app(). IIRC, WhatIsADocument talks about
this.

--
Karl Anderson kra@monkey.org http://www.monkey.org/~kra/

Karl Anderson wrote:
> Martijn Faassen <faassen@vet.uu.nl> writes:
>
> > The problem is that David Mertz' XML pickle strategy pickles object
> > attributes, but doesn't do much about methods. The equivalent would be
> > exposing to the DOM (as attributes or perhaps as sub element nodes or
> > a mixture) the attributes of some persistent Zope object.
> >
> > That's not very useful in the Zope content for a number of reasons:
> >
> > * security; the innards shouldn't be exposed like that generally.
> > Normally you get to this by using methods which do security checks,
> > etc.
>
> Well, I never thought that ZDOM would interact with the security
> mechanism in a DOMish way. A DOM method such as attributes() would
> return whatever the security context allowed, just like any other
> method called with a security context, but the restricting wouldn't
> have anything to do with how the DOM calls are invoked.

Right, I'm not sure I was claiming it would. What the DOM adapter
would have to do is make sure the user is actually allowed to use the
methods the adapter is calling to construct the DOM representation.

But here I was objecting to the idea to generate a DOM representation
automatically by looking at the object innards (i.e. private
attributes), instead of using an adapter approach.

An compromise approach later discussed in this thread would be
semi automatic way to translate Zope API to DOM representation. This would
make make adapter construction a lot easier.

> In other words, a Python call of a ZDOM method would be as
> unrestricted as any other Python access of the DB, while a
> hypothetical XPath access of ZDOM invoked via a web interface would
> only see what was allowed by that interface's security context.

Right, if you use unrestricted Python it should just return as much
as possible. The implementation would be using unrestricted
Python, however, wouldn't it? So we'd need to check there explicitly,
(or pass some security context along?) unless I'm missing something.
Is this automatic?

> But
> that security isn't expressed meaningfully by the DOM, it's expressed
> by the fact that these are still Zope objects - that is, a ZDOM object
> might have an ac_permissions DOM attribute, but security isn't handled
> by accessing that interface thru the DOM, and the custom adapter (like
> mentioned below) might not even expose it.
>
> IOW, security doesn't change. I never thought too hard about it,
> though, is this a naive?

Well, it's basically what I'd like to implement, but wouldn't the
ZDOM implementation be unrestricted Python, just like an external method
or any product method? I.e. if you can bypass the security by going through
ZDOM that'd be bad. You can't just restrict access to ZDOM methods with
security declarations to fix this, either. The ZDOM methods themselves
need to check for permission, right?

> > What needs to happen, and why I think a registry of adapters is unavoidable,
> > is that we expose what's accessible through object's APIs to the DOM somehow.
> > So, an objectValues() would turn into a list of childNodes. Properties
> > and other attributes can often become attribute nodes. Text contained by
> > some object can become a text node. The representation to the DOM should:
>
> Adapters are unavoidable because the DOM is document-centric.
> Otherwise the only way to look at the ZODB would be as one large
> document rooted at Zope.app().

Because you'd need to construct the entire XML representation of the entire
tree in one go otherwise? Yes, adapters are 'lazy', which is good, but
I was talking about the need for a *registry* of adapters instead of
having some form of super adapter that does the translation fully
automatically (or adding a super mixin to objects to do this DOM
representation).

Regards,

Martijn