I had in mind to use DTML documents as the storage mechanism for the main documents at the core of an application I'm building for a client, but it turns out they are going to need to do some things that would be pretty cumbersome in a DTML document or method. So I'm investigating using XML for these documents. Searching zope.org turns up a lot of stuff about XML but, as far as I can tell, only one product: XMLDocument. But it describes itself as out of date and replaced by ParsedXML, which, as far as I can tell, hasn't had a product release yet. I can't tell from the ZQR which XML implementation it is documenting. This is all made more complex by the fact that I cannot for the life of me get an external script using any of the xml library stuff to run, but I'm not asking for help with that at the moment. I'm trying to work my way through it. So should I download and install the XMLDocument product and use it from DTML (ugh) or is there a better way to do this?
Dan Shafer wrote:
I had in mind to use DTML documents as the storage mechanism for the main documents at the core of an application I'm building for a client, but it turns out they are going to need to do some things that would be pretty cumbersome in a DTML document or method. So I'm investigating using XML for these documents.
Searching zope.org turns up a lot of stuff about XML but, as far as I can tell, only one product: XMLDocument. But it describes itself as out of date and replaced by ParsedXML, which, as far as I can tell, hasn't had a product release yet.
I can't tell from the ZQR which XML implementation it is documenting.
XMLDocument is out of date. The ZQR is no longer maintained. ParsedXML is dead as it currently has no maintainer (well, bar Martijn, who's busy on the Zope 3 effort and not subscribed to this list...) To be honest, if you explained the problem we might be able to suggest an alternate solution... cheers, Chris - XML: the world's most inefficient data transfer format
OK, I'll be happy to describe the problem. I'll try to be brief but clear. In the briefest terms I can come up with: I need a way of storing a document-like object in the ZODB which will be sufficiently structured to allow the selective display and replacement of its elements while allowing for the immediate display of its contents as a nicely formatted document in a browser. Now for the longer-winded version for those with the patience or curiosity to read more. I am building an application which is quite document-centric. When the client interacts with the application, he is building a "record" of an interaction with a patient. This interaction can extend over a period of days, so it needs to be able to be resumed. The application now consists entirely of HTML forms which trigger Python scripts that initially create and then update a DTML Method object. I embed formatting into the DTML Method so that when the user wants to see a report of the patient interaction, all I have to do is give him a way to view the document. The client *loves* the application as it has developed so far, in part because as the code updates the DTML Method during the patient interaction, a supervising clinician can see the progress of the interaction as it develops. So I prefer not to lose the ability to allow the supervisor to see the document the code is generating, but I may have to do so. When the interaction with the patient proceeds linearly and in one session - which is most often the case - this system works like a charm. But if for any reason the interaction gets interrupted, my scripts, which always merely *append* information to the end of the document as each step proceeds, are not now capable of a smooth resumption in place. This would require, e.g., that information now stored in the DTML Method be parsed out to supply initial values to fields on the interactive form that have already been completed. That is the minimum I need, but as I have been thinking about the design, I've decided I actually need much more than that. I believe the best way to accomplish that objective of maximum flexibility for the user is to use a more structured approach to the document. As I see it, I had three alternatives: (1) parse the text in the DTML Method to pull out and rewrite pieces as needed; (2) use properties of the DTML Method in addition to text content and link the two; (3) go to XML to take advantage of readily available Python techniques for managing the structured data while being able to use XSLT to retain the ability to show the document in process immediately on demand. I spent some time looking at the first option and decided it was going to be terribly inefficient. I would in essence have to define my own start/end tags for each element of the document (which I could use comments for) and then manually parse them. Ugly. The second approach also felt inefficient because I would be storing all of the information in a document twice, once as a document (so that it could be displayed quickly on demand) and once as properties (so they could be retrieved and replaced as needed). I have not completely discarded that approach but XML seems more promising. I am fully aware of the horrendous overhead associated with XML documents but these documents are quite small (3-4 pages on average, printed) and always identically structured. With Python's excellent XML support, I have already gotten some very good routines written to parse such documents. My problem is that when I try to translate that code to Zope External Methods, they don't work and debugging them in Zope is a nightmare. I am learning, and I am open to any suggestions or corrections to my thinking. I appreciate the group's patience with me and any ideas you have. At 09:18 AM 5/15/2002 +0100, Chris Withers wrote:
Dan Shafer wrote:
I had in mind to use DTML documents as the storage mechanism for the main documents at the core of an application I'm building for a client, but it turns out they are going to need to do some things that would be pretty cumbersome in a DTML document or method. So I'm investigating using XML for these documents.
Searching zope.org turns up a lot of stuff about XML but, as far as I can tell, only one product: XMLDocument. But it describes itself as out of date and replaced by ParsedXML, which, as far as I can tell, hasn't had a product release yet.
I can't tell from the ZQR which XML implementation it is documenting.
XMLDocument is out of date. The ZQR is no longer maintained. ParsedXML is dead as it currently has no maintainer (well, bar Martijn, who's busy on the Zope 3 effort and not subscribed to this list...)
To be honest, if you explained the problem we might be able to suggest an alternate solution...
cheers,
Chris - XML: the world's most inefficient data transfer format
[Dan Shafer]
I am fully aware of the horrendous overhead associated with XML documents but these documents are quite small (3-4 pages on average, printed) and always identically structured. With Python's excellent XML support, I have already gotten some very good routines written to parse such documents. My problem is that when I try to translate that code to Zope External Methods, they don't work and debugging them in Zope is a nightmare.
I am learning, and I am open to any suggestions or corrections to my thinking. I appreciate the group's patience with me and any ideas you have.
Dan, I do XML processing and xslt transformations using Python and external methods, and it works very well. Also, I don't think that XML necessarily incurs such "horrendous" overhead. The key to having it work well is, I think, to have one simple external method call to the python scripts that do all the work, and have them return strings or arrays to the DTML page for formatting. If you do an xslt transformation to produce a complete html page, all you need on the dtml page may be a single <dtml-var "yourMethod(....)"> This way, you can debug the python scripts like any other python code (that is, outside of Zope), and when it works, just call it from Zope. Make sure to keep your programs out of the Zope directory tree, and make them accessible by using a .pth file in the Zope bin directory (or wherever Zope's Python executable file ends up). Here is one complete page for processing a form, receiving XML from the form (stored in a hidden variable), sending it to an external python program via an external method, receiving and XML string back, and then transforming that to the final html page. # =================================================== <dtml-let xml="runSAERoute(_['REQUEST']['xml'],_['REQUEST']['live'][0])"> <dtml-let xsl="getBasepath()+'\\stylesheets\\routeInfoDisplay_4.xsl'"> <dtml-var "transform_xml_string (xml,xsl)"> </dtml-let> </dtml-let> # =================================================== You see how simple it is. I make one call to create the output XML (which we want for some other reasons that don't matter here), and one more to run an xslt transformation, for which I use 4xslt (but there are other possibilities). Here, runSAERoute(), getBasepath(), and transform_xml_string() are called via external methods. Those methods, though, just do simple function calls to the real code. runSAERoute() is actually about 1000 lines of Python code that lives outside the Zope directory tree. You can have the external code store data in the file system if you like - use a directory relative to the base module because you can always find its location programatically. (Yes, I know I hard-coded the path separators. Yes, I know it's better not to.) I don't see why something like this wouldn't work just fine for you. Cheers, Tom P
Dan Shafer wrote:
I had in mind to use DTML documents as the storage mechanism for the main documents at the core of an application I'm building for a client, but it turns out they are going to need to do some things that would be pretty cumbersome in a DTML document or method. So I'm investigating using XML for these documents.
Searching zope.org turns up a lot of stuff about XML but, as far as I can tell, only one product: XMLDocument. But it describes itself as out of date and replaced by ParsedXML, which, as far as I can tell, hasn't had a product release yet.
http://www.zope.org/Members/karl/ParsedXML/ParsedXML
I can't tell from the ZQR which XML implementation it is documenting.
This is all made more complex by the fact that I cannot for the life of me get an external script using any of the xml library stuff to run, but I'm not asking for help with that at the moment. I'm trying to work my way through it.
So should I download and install the XMLDocument product and use it from DTML (ugh) or is there a better way to do this?
-- ------------------------------------------------------------- Who's got only a hammer sees the world as a nail hans augustin (software developer) hans@beehive.de beehive elektronische medien GmbH http://www.beehive.de phone: +49 30 847-82 0 fax: +49 30 847-82 299
At 10:41 AM 5/15/2002 +0100, hans wrote:
Dan Shafer wrote:
Searching zope.org turns up a lot of stuff about XML but, as far as I can tell, only one product: XMLDocument. But it describes itself as out of date and replaced by ParsedXML, which, as far as I can tell, hasn't had a product release yet.
http://www.zope.org/Members/karl/ParsedXML/ParsedXML Wow. I know I looked. I must have managed to overlook this page. Sorry. Thanks. I'll go look at it, even though Chris suggested this is no longer being developed actively. If it does what I need, I can use it and maybe even take over its development some day in the far, far distant future if needed!
[Dan Shafer]
I had in mind to use DTML documents as the storage mechanism for the main documents at the core of an application I'm building for a client, but it turns out they are going to need to do some things that would be pretty cumbersome in a DTML document or method. So I'm investigating using XML for these documents.
Searching zope.org turns up a lot of stuff about XML but, as far as I can tell, only one product: XMLDocument. But it describes itself as out of date and replaced by ParsedXML, which, as far as I can tell, hasn't had a product release yet.
I can't tell from the ZQR which XML implementation it is documenting.
This is all made more complex by the fact that I cannot for the life of me get an external script using any of the xml library stuff to run, but I'm not asking for help with that at the moment. I'm trying to work my way through it.
So should I download and install the XMLDocument product and use it from DTML (ugh) or is there a better way to do this?
So far I'm doing all my xml work in Zope using external methods. I basically have some xml-producing and -consuming Python applications and interface to them using external methods. I use 4xslt for transformations, called from dtml via an external method. Works well. Cheers, Tom P
participants (4)
-
Chris Withers -
Dan Shafer -
hans -
Thomas B. Passin