Ahh, a topic about which I have a lot of interest... Eron Lloyd wrote:

Is there a way to convert, say, a DTML Method into a DTML Document? By this, I mean only changing it's object-type property? Could I add a

I don't think it is as simple as that. It's true that Zope objects have a property "meta_type" that provides a label for the kind of thing they are. But they are all instances of a class. DTML Methods are a different class than DTML Documents. Thus, you'd have to think in terms of destroying the old instance and creating a new instance of a new class with the same id and data as the old one. I imagine this would have a lot of unintended side effects. We've been thinking of re-uniting these two by making the Document vs. Method "behavior" switchable without changing the class or the object id (or the database object id).

property to objects to allow their conversion, so the system would only look for those having this "switchable" property? Also, when I download a file using FTP or WebDAV, make changes, and then upload it back into Zope, where in the object is this property-type determined? A downloaded

Zope has a "magic" system like Unix and others that infers content type from a number of parameters. If the interaction is HTTP and Content-Type is provided, that is used to map into object type. If not, file extensions are used. This is definately an area ripe for improvement. But it's a pretty hard problem.

DTML Method looks like a simple text object when viewed through a text-editor...what if when I uploaded it I wanted it to be a Document? Does Zope insert an ID that remains in the Database?

These questions are posed with thoughts of possibly coming up with a small GUI tool, that could be used as a sort of PyGNOME (or equivalent) content management that consisted of a Frontend to the Main.py Zope interface, where objects could be created and manipulated. XEmacs and FTP are ok for me, but for the content managers and users, a nice GUI tool would make Zope become adoptable easier. Also there is an idea to provide GNOME with WebDAV folders, since there really isn't much support for WebDAV under Linux thus far.

You're definately right on this. A number of points... First, if you have a rich programming environment, you'll have no problems. Why? Because you control what method gets called when you construct an object. FTP doesn't know when to call manage_addDTMLDocument or manage_addDTMLMethod. You can use all the power of the GUI and Python to collect or infer that decision. Second, although I use Emacs a *lot* for editing Zope content lately, I think its days are limited. FTP isn't an object system. I find myself awfully constrained, particularly by the detail of not being able to create a "News Item", but generally by the thunk in mindset. Concerning GNOME and WebDAV. I've spent some time corresponding with Miguel, Nat, and some of the other GNOME guys about this. GNOME is on the way to a generic abstraction with Bonobo, but it isn't there yet. The new file manager, the PIM, and many other GNOME application will stop opening files directly and will start going through Bonobo to get to them. This is good because Bonobo handles the back-end transparently. "Files" might be on the local filesystem, a Samba filesystem, an FTP server, etc. Since Bonobo is a CORBA component model, you get cross-language access. Sound good? Not so fast my friend. Bonobo is still a file-oriented component. Meaning, the semantics of stat still prevail. Want to do a PROPFIND from WebDAV? Bonobo will say, "We don't know no stinking PROPFIND. Files don't have no stinking properties." This means that, IMO, Bonobo isn't about accessing content-like objects, its about accessing file-like object. So you could jump in on the Bonobo list and (a) see if I've repeated it incorrectly, and if so, (b) convince them to provide richer semantics. Without richer semantics, Bonobo will feel a whole lot like ange-ftp as far as interacting with Zope. This doesn't mean that you can't do the above. You could create a GNOME CORBA component that provided a much richer interface to managing content. I would *love* to see that. There are probably a lot of interesting interfaces and protocols that you could start with, such as WebDAV or DOM. You then implement your component in a way that it's easy to plug in new front-end (e.g. WebDAV, XML-RPC) and back-end (e.g. Zope, filesystem, Samba, Bonobo) architectures. I imagine that, for someone that really knew PyGNOME and the GNOME component model, constructing a prototype would be straightforward. However, for someone that *didn't* know the GNOME component model and CORBA, it would be a long road indeed. I have other interests in wanting to see this, beyond wanting a better management environment for Zope. The GNOME team is working on a groupware application. So far they have spent much of their time thinking about the front end, but they don't really have a calenar server, etc. I think that, if they defined a good interface, Zope would be a great platform. I shudder to think they might store all that rich content in MySQL. --Paul