Sean.... Thanks for the in-depth answer. My comments are inline. At 03:45 PM 5/18/2002 -0700, sean.upton@uniontrib.com wrote:
I would think ParsedXML+DOM in Python Scripts+DTML/ZPT would work here??? Contrary to popular belief, I don't think ParsedXML is "dead" - it works quite fine, thank you, for all the DOM L2 stuff I do, which is likely why there hasn't been a lot of development... and I've seen that Martijn Faassen has been doing some small improvements in CVS in the last few days. All this assumes small documents like forms and news-articles, not book-sized docs, since nodes in a ParsedXML doc are not manageable, so each edit reqires the whole DOM from the document object downward...
These documents are in fact quite small. Never more than 3-4 pages of fairly sparse text when displayed in HTML and printed.
I've used this type of setup for interactive form applications as well as XML-stored content applications and been quite happy, but I've been doing a lot of DOM-in-python-scripts coding; it is a bit tedious to code for, there is a lot of recursion to think about, etc.... but once you get it right, it just works...
It will undoubtedly take me some time to come up to speed on all this syntactical stuff, but I'm sure I can grok it. The biggest problem I have trying to code Python scripts in Zope is the virtual absence of debugging tools in the environment.
Alternately, I think you could put any Python XSLT on top of this with a few external methods, though I think it's a bit hackish since you would be printing XML, outputting it to a string, and having it parsed again (but, hey, if it works...) - as long as you are not indexing the results of XSLT in a Catalog index for a bunch of docs!
Yeah, probably not essential. If I store the document objects in XML form, I'll have to display them in HTML but there's nothing fancy in them.
As an aside, it sounds like you need to make a lot of revisions to your documents, and if you store them in the ODB it might create bloat in a versioned ODB unless you pack frequently. A brief thought for you: create something that will do application-level versioning and use non-undo mounted storage for a repository for your documents...
Actually, there are not a lot of revisions made to the documents. Typically, there are none! About 10% of the documents involve processes that are for one reason or another disrupted and need to be resumed. Only rarely is editing of previously captured content necessary or even appropriate. So I think the versioning won't be an issue. I've discovered and downloaded XMLKit. I'm just starting to explore it but if anyone has a viewpoint about it I'd love to hear it. I may *still* end up just deciding to use a fodlerish object (actually, a Zope folder as it turns out) with DMTL Methods inside it for the contents of the process record rather than trying to stuff it all into one document. Then I just have the complexity of figuring out how to create a nicely formatted HTML document containing the data in the folder's documents. I suspect that, at least, is manageable. All of this because ZClasses aren't what I'd hoped they'd be. I started in Zope because I really love creating OO designs and apps. Folders as containers and documents as objects containing properties will work OK for this app but in the long run I either have to switch platforms or figure out how to get around whatever the problems and limitations are with ZClasses. I remain teachable!
-----Original Message----- From: Dan Shafer [mailto:pydan@danshafer.com] Sent: Wednesday, May 15, 2002 9:45 AM To: Chris Withers Cc: Dan Shafer; zope@zope.org Subject: Re: [Zope] XML in Zope
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
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )