RE: [Boa Constr] Re: Zope Support

[Riaan B. <ri...@tb...>]

Hello Yuppie,

> Hi Riaan!
>
>
> Riaan Booysen wrote:
> > From my investigations into this it looks like CMF objects can
> be wrapped
> > just like all the other Zope objects currently supported.
>
> There's on thing that could cause trouble:
> Some meta types (e.g. 'Document') have a different text format ('html',
> 'structured-text' or 'plain') depending on their text_format attribute.
> How would I implement different editing views for one Node class
> depending on an attribute? Or how would I get different Node classes for
> instances of one meta type?

Ouch, this could be painful.

I suggest a workaround like this:
Let zoa/metatype return Document:html, Document:structured-text or
Document:plain.
Then can have 3 Node classes for the different types (with a common base
class to capture shared behaviour)

This is not ideal, do many CMF objects work like this?

> >>The Zope plug-ins are very different to the other plug-ins.
> Looks like a
> >>unified plug-in interface would be very helpful for updating the
> >>ZopeExplorer to Zope 2.6 or writing a CMF plug-in.
> >
> > No. Those comments aren't that accurate anymore.
> > It has already been unified in the sense that
> > Editor.openOrGotoModule('zope://Connection/<meta>/path/obj')
> > works correctly and that Zope items can be bookmarked.
>
> One thing that confused me was this:
>
> Views are defined
> - for Zope in the node as defaultViews / additionalViews
> - for the rest in the controller as DefaultViews / AdditionalViews

Yes that's the way it is (part history, part necessity), don't worry about
it,
all the Zope support works like this.

It's better this way because there is currently just one Zope Controller
class. If the view definitions moved to Controllers I'd have to
mirror all the Node classes.

> > Nevermind the differences between Zope transports and the simple
> > transports, just use the current Zope support as examples,
> > they all follow basically the same model.
>
> Maybe you could give me some hints. I quote ZopePTHTMLView because I
> have some questions about it.

ZopePTHTMLView is a bit non standard.

>
> class ZopePTHTMLView(ZopeViews.ZopeHTMLView):
>      viewName = 'Source.html'
>      def generatePage(self):
>          props = self.model.zopeObj.properties
>          url = 'http://%s:%s@%s:%d/%s/source.html'%(props['username'],
>                props['passwd'], props['host'], props['httpport'],
>                self.model.zopeObj.whole_name())
>          import urllib
>          f = urllib.urlopen(url)
>          return f.read()
>
> Q1) zopeObj doesn't work. Should be 'self.model.transport'. Right?

Right, thanks!

> Q2) generatePage() is used by additional read only views. For editable
> data I have to use load() / save(). Right?

Close. generatePage is only used in HTMLView derived classes to
provide the html to render.

Model classes usually handle IDE loading and saving (by calling the
transport's load() / save().
This saves/loads the data for views's that maintain model.data.

Zope Views like Undo or Security also "load"/"save" because
they call xmlrpc methods on the server.

> Q3) urllib.urlopen() is a workaround. I should better use getResource()
> if possible. Right?

Yes, it's a workaround. It's the only way I could get it to work.
Try accessing source.html with xmlrpc ;)

So yes, use getResource if possible, otherwise use a ZopeConnection
(based on Zope's client.py), otherwise use whatever works.

> > Please go ahead and implement CMF support!
> > Even just a (working!) prototype would be great.
> >
> > If I ever refactor the Zope support further, I promise to also update
> > the CMF support if its there ;)
>
> Thanks. I'll see what I can do.

Great!

Cheers,
Riaan.