Simplification via custom protocol handlers: cvs://server/project, zope://foo ?
Hello: I am the author of the CVSFile product, available at http://www.zope.org/Members/arielpartners/CVSFile I am thinking about implementing a new design, and wanted to get some feedback from the list first (perhaps others have tried this approach?) Here is a description of our problem: ExternalFile is a Zope product that behaves like a DTMLDocument/method/etc but points to a file outside of ZODB for its content (sort of like a symbolic link) CVSFile inherits from ExternalFile, where the content file is stored in a CVS sandbox. It features buttons to do updates, commits, etc. So far, so good. The problem is that we are working on a third Zope product whose instances represent XML documents that automatically render themselves to HTML (or whatever) when referred to. You edit the XML content using ZMI or whatever, but when you navigate there, you see the resulting web page/PDF/etc. We are going to call it something along the lines of XSLTFile because it uses XSLT to do the conversion. Here's the issue: the XML file that is the source of the transformation may or may not reside inside the ZODB. For example, we store most of our XML documents in CVS. But if revision control is not important (such as for one-off or throw-away documents) we keep them in ZODB. How did we do this? Well we had XSLTFile inherit from CVSFile. This is bad. What happens when we switch to some other revision control tool (like clearcase, subversion, sourcesafe)? Either you have multiple classes like "CVS-XSLTFile, Clearcase-XSLTFile, etc." or a single class that knows about every possible version control system. yuk. Clearly, inheritance and mixins are not the answer. Instead we want delegation. How to do this? One idea is to register a custom protocol handler with python, using urllib2. See: http://www.python.org/doc/current/lib/module-urllib2.html install_opener() I am imagining the following. a new XSLTFile instance is created, pointing to a URL for its content. Here are some examples of URLs: cvs://myserver/myproject/my/file#VERSION-10 zope://foobar http://www.foo.bar/myfile In this way, the XSLTFile instance knows nothing about CVS or any other revision control system. Instead, it only knows about a URL, and the CVS protocol handler would know about how to retrieve files from CVS. We could create our own scheme where a query parameter would specify the sandbox name or something. The Zope protocol handler idea is interesting, and I haven't thought this all the way through yet. Could <dtml-var blat> be thought of as referring to "zope://blat" where the Zope protocol is the default and therefore omitted? The idea of unifying all object references through URIs is intriguing to me. (for more info, see REpresentational State Transfer: http://conveyor.com/RESTwiki/moin.cgi ) Comments? --Craeg
is bad. What happens when we switch to some other revision control tool (like clearcase, subversion, sourcesafe)? Either you have multiple classes like "CVS-XSLTFile, Clearcase-XSLTFile, etc." or a single class that knows about every possible version control system. yuk. Clearly, inheritance and mixins are not the answer.
If I understand you correctly, you are hitting exactly the problem that the Z3 CompoentArchitecture is designed to solve, which it does in a more general way than your URI based scheme. You might want to take a look, though it probably doesn't do you any immediate good. --RDM
Craeg K Strong writes:
... The Zope protocol handler idea is interesting, and I haven't thought this all the way through yet. Could <dtml-var blat> be thought of as referring to "zope://blat" where the Zope protocol is the default and therefore omitted? I do not think, this would be a good correspondence:
"zope://blat" is kind of an absolute URL while "blat" is by no means absolute. Dieter
Dieter Maurer wrote:
Craeg K Strong writes:
... The Zope protocol handler idea is interesting, and I haven't thought this all the way through yet. Could <dtml-var blat> be thought of as referring to "zope://blat" where the Zope protocol is the default and therefore omitted? I do not think, this would be a good correspondence:
"zope://blat" is kind of an absolute URL while "blat" is by no means absolute.
Dieter
You're right, it is a different thing. I was originally thinking that you could imagine a URN with a "zope" namespace ID (meaning the entire contents of the ZODB) and the python expression as the namespace specific string. However, I believe URNs are supposed to name a specific resource. By contrast, acquisition means that a dtml-var can name very different resources depending on what is in the ZODB. It is a variable, not a name. I am now thinking that the way to avoid my multiple mixin problem in Zope-2 is to break things apart into small pieces that each do a specific thing. For example, you could have: - a CVSFile product that makes an object in ZODB retrieve its content from a CVS sandbox - an XPath filter product that applies an xpath to an object in ZODB and returns the result - an XSLT transformer product that applies an xslt to an object in ZODB and returns the result - a STX to Docbook filter product that takes an ASCII file in structured text format and returns an XML file using the docbook dialect (I think STXDocument does this) So you could have a structured text document foo.stx in your CVS sandbox. A contrived example follows. Lets say you wanted an HTML page that displayed only a portion of the contents of a structured text file. The file ("foo.stx") is in your CVS sandbox, and you just want the first paragraph as an HTML page. You would create an instance of CVSFile called foo.stx in ZODB. foo.stx gets its content from the file "foo.stx" in your CVS sandbox. You would then create an instance of STXDocument that gets its content from foo.stx but transforms it into docbook XML. You might call it foo.xml You could then create an instance of XPathFilter that gets its content from foo.xml but just picks out some subset of that content based on the specified xpath. You might call that object "bar.xml" Finally, You could create an instance of XSLTFile that gets its content from bar.xml and applies an xslt transformer to it to output HTML. You might call this file "index_html" So inside a single folder in ZODB you could have your four different objects: folder/foo.stx (instanceof CVSFile) folder/foo.xml (instanceof STXDocument) folder/bar.xml (instanceof XPathFilter) folder/index_html (instanceof XSLTFile) So by navigating to "folder" you automatically get the HTML webpage with the desired content. How to make this work? Each Zope Product must be able to either hold its content directly or get its content by referring to another object in ZODB. Also, if the Product maintains a cache (obviously you don't want to run a transformation more than once on the same content) it must ask the referrred to object if its contents have changed. Thoughts? --Craeg
participants (3)
-
Craeg K Strong -
Dieter Maurer -
R. David Murray