RE: [Zope] Editing DTML Methods with Emacs ?
Gregor wrote:
I remember this problem was raised here once, but I don't know if there's a solution now: I'd like to use something else than Netscape's text widget to edit my Zope site. XEmacs would be preferred. Ftp access to the site does work with the /superuser@host#8021:/ syntax. The problem is that if I edit and save a DTML method with XEmacs, the method turns into a DTML document, breaking the logic of the site.
I think I understood the underlying problem (ftp just can't express the differences between the objects), but I don't remember if there was any workaround.
This, I'm afraid, is a big problem. Trying to get a dumb object system (FTP) to play with a smart object system (the web object model) is quite problematic. I can tell you the basic idea we have around here to address this, but I'll warn that there is no activity to implement. Thus, consider this a suggestion, and I'll note that patches are accepted. :^) Basically, one proposal allows _all_ objects to have a discoverable XML interface via FTP. You walk up to a Folder. You see a special folder, perhaps "mgmt". You go into that folder and you see a bunch of things that look like files, such as "addFolder.xml". You GET that "file", edit it. When you save it, Zope makes the appropriate change. The benefit here is that you can express all kinds of metadata. You certainly can manipulate all the built-in classes (folders, etc.), but you can also grab Python products and ZClass products. You can also get at the interface to edit properties, change security settings, etc. In some cases this interface could be more convenient that the current one. For instance, you edit a "listAllDTMLDocuments.xml" file that contained an XML representation of all the folder's DTML Documents. You could then do a global search and replace using standard Emacs/XEmacs tools. Alternatively, you could create a .xml "file" that let you add ten things at one time. Essentially you take stupid files, find a way to express richer semantics (XML), then use this to script the Zope object system. Just my $0.02. Again, this isn't on the radar, but some discussion has been put into it. --Paul Paul Everitt Digital Creations paul@digicool.com 540.371.6909 ----------------------------------------- The Open Source Zope application server http://www.zope.org/
On Tue, Sep 07, 1999 at 10:21:04AM -0400, Paul Everitt wrote:
This, I'm afraid, is a big problem. Trying to get a dumb object system (FTP) to play with a smart object system (the web object model) is quite problematic.
I can tell you the basic idea we have around here to address this, but I'll warn that there is no activity to implement. Thus, consider this a suggestion, and I'll note that patches are accepted. :^)
The proposal sounds very promising. Still I wonder if there's perhaps an easier fix for the problem: Is there a reason that uploading an object via ftp has to discard/change the properties of an existing object with the same names ? Perhaps the behavior of ZServer could be modified so that if an ftp upload would replace an DTML method, then the new object still will be a DTML method. Currently, Zope seems to have some magic that makes a guess that the upload it DTML text and then, there's a hidden default that DTML text will be saved as an DTML document. Now if Zope simply would default to keeping the type of the object, if it already exists, editing via ftp would be much easier, not ? Gregor
Perhaps I don't understand the complexity of the problem but couldn't Zope just prefix a header that will "remind" it that the document is DTML. Or what if it added an extension to the object name? Paul Prescod
Hi, Ok... <SOAPBOX> "Languages" that do not have a 'external' representation really "get my goat". There is no reason to not have a "source code" representation for anything that appears in a symbol table (e.g. the 'internal object structure'). I want source1->encode->structure->decode->source2 such that if I apply the above to my source creating source1, and then apply it again to source1 resulting in source2, source1 and source2 are character identicial (comments and all), and except for use of "white space" both source1 and source2 are character identical to my original source. (Like I can do with indent(1) to enforce a 'shop coding style standard'). </SOAPBOX> In reading Paul's reply, I am reminded of what /proc does... (To my knowledge) nothing in /proc is a "real" file, but open(), read() etc don't seem to notice that. Likewise, the "source" interface to ZOPE could have an ftp (or even 'mountable filesystem') "appearance" for the navigational/organizational aspects (object hierarchy). The contents of each object (IMO) *must* have a source code representation, which is fully capable of representing all aspects of the object, but in a "conventional" format (not XML). The fact that XML is capable of representing everything in ZOPE, it seems that a suitable set of DTD/mapping/magic would render (decode) any ZOPE object into a 'suitable' (<retronym>human</retronym> language independent) source code, and could drive a "compiler" that would translate (encode) a source back into the internal object structure. Essentially, what I am suggesting would be to add a layer between people and the existing XML interface, where there is a 1:1 relationship between each "source code construct" and each "object structure construct". ftp | /--->Encoder-->\ fs |Source- | --XML--ZOPE etc | Code \<---Decoder<--/ \ DTD/mapping/magic (vulgar localizations) In fact, this interface notion would be useful regardless of the "source" code, even XML. Maybe I am missing something, but it seems to me that the XML encode/decode interface is mostly (if not completely) done. The questions that I have are: 1. How well does the import/export function deal with 'partial' trees It seems to me that this is important for working on a single ZOPE instance, or collection of instances, irrespective of the hierarchy from which they may have been selected. 2. Can the acquisition expectations (of an object) be stated, or explicitly encoded so that the encoding of an object more or less 'stands alone' (that is, acquisition expectations be identified by name so that any willing supplier of that name is acceptable. This is probably currently a weak link because (from what I've seen, the XML representation is accomplishing the encoding of these dependencies by "nesting" the specs. IMO, the dependencies need to have explicit encoding rather than a "inclusive scoping" (akin to what we have in explicit transistors vs nested gates, or explicit gates vs nested chips, in a circuit). 3. Object ids. This is potentially beyond what I think I know about... What I am concerned about includes... o If object ids are, or can be globally unique, then how does one deal with the importing of such an object? o Does the mere changing of the object (you would be 're- compiling' it) cause it to get a new object id? o What happens if I import your source? How and when does that object id get assigned (I'm thinking in the CORBA sense here)... or o Are ZOPE objects "below the line", so to speak (e.g. they are not published beyond the "local container"? o How do I publish a ZOPE object's services beyond the "local container" (thinking of distributed/migratable objects here, where I'd use something like CORBA directory services to get to the object's services)... Paul Everitt wrote:
Gregor wrote:
I remember this problem was raised here once, but I don't know if there's a solution now: I'd like to use something else than Netscape's text widget to edit my Zope site. XEmacs would be preferred. Ftp access to the site does work with the /superuser@host#8021:/ syntax. The problem is that if I edit and save a DTML method with XEmacs, the method turns into a DTML document, breaking the logic of the site.
I think I understood the underlying problem (ftp just can't express the differences between the objects), but I don't remember if there was any workaround.
This, I'm afraid, is a big problem. Trying to get a dumb object system (FTP) to play with a smart object system (the web object model) is quite problematic.
I can tell you the basic idea we have around here to address this, but I'll warn that there is no activity to implement. Thus, consider this a suggestion, and I'll note that patches are accepted. :^)
Basically, one proposal allows _all_ objects to have a discoverable XML interface via FTP. You walk up to a Folder. You see a special folder, perhaps "mgmt". You go into that folder and you see a bunch of things that look like files, such as "addFolder.xml". You GET that "file", edit it. When you save it, Zope makes the appropriate change.
The benefit here is that you can express all kinds of metadata. You certainly can manipulate all the built-in classes (folders, etc.), but you can also grab Python products and ZClass products. You can also get at the interface to edit properties, change security settings, etc.
In some cases this interface could be more convenient that the current one. For instance, you edit a "listAllDTMLDocuments.xml" file that contained an XML representation of all the folder's DTML Documents. You could then do a global search and replace using standard Emacs/XEmacs tools. Alternatively, you could create a .xml "file" that let you add ten things at one time.
Essentially you take stupid files, find a way to express richer semantics (XML), then use this to script the Zope object system.
Just my $0.02. Again, this isn't on the radar, but some discussion has been put into it.
--Paul
Paul Everitt Digital Creations paul@digicool.com 540.371.6909 ----------------------------------------- The Open Source Zope application server http://www.zope.org/
-- Cheers, --ldl ----------------------------------------------------------------------------- LD Landis ldl@HealthPartners.Com N0YRQ Voice 612/883-5511 Fax 612/883-6363 HealthPartners, 8100 34th Avenue So, PO Box 1309, Minneapolis, MN 55440-1309 Shape your life not from your memories, but from your hopes. (Borrowed) -----------------------------------------------------------------------------
LD Landis wrote:
<SOAPBOX> "Languages" that do not have a 'external' representation really "get my goat". There is no reason to not have a "source code" representation for anything that appears in a symbol table (e.g. the 'internal object structure').
I want source1->encode->structure->decode->source2 such that if I apply the above to my source creating source1, and then apply it again to source1 resulting in source2, source1 and source2 are character identicial (comments and all), and except for use of "white space" both source1 and source2 are character identical to my original source. (Like I can do with indent(1) to enforce a 'shop coding style standard'). </SOAPBOX>
Two observations: 1) Does the XML Export accomplish roughly what you want? Namely, a mostly-text representation that can be round-tripped. 2) What do you do when your source can also have state? That is, your source is stored as a rich object in a database, and can have run-time settings (permissions, properties, etc.). Uou are asking for both your source *and* your database to exhibit the above. Thus, can you name a database system that doesn't "get your goat"?
In reading Paul's reply, I am reminded of what /proc does... (To my knowledge) nothing in /proc is a "real" file, but open(), read() etc don't seem to notice that. Likewise, the "source" interface to ZOPE could have an ftp (or even 'mountable filesystem') "appearance" for the
I'd love for someone to write a mountable filesystem for Zope, but I'm not sure how much it would help. Zope has a lot of semantics that stat doesn't cover. The problem here isn't how to get the object. The problem is how to express the object once it is gotten in a way that old-style, file-oriented programs and protocols (e.g. Emacs and ftp) can still participate. The problem, and the goat :^), are as much with all the editors in the world and their protocols as it is with Zope. I could easily change your goat to say "All editors and IDEs should work with the web object model." :^)
navigational/organizational aspects (object hierarchy). The contents of each object (IMO) *must* have a source code representation, which is fully
Again, do you make the same demand of Oracle/MySQL? If so, how do they accomplish it?
capable of representing all aspects of the object, but in a "conventional" format (not XML).
Please name the format you're thinking of. If you ask nearly anyone on this list, "Name the standard for clear-text encoding of dynamic content", I imagine XML would get the most votes. I personally can't think of many other choices. Perhaps we could use the Python text-based pickle format. :^)
The fact that XML is capable of representing everything in ZOPE, it seems that a suitable set of DTD/mapping/magic would render (decode) any ZOPE object into a 'suitable' (<retronym>human</retronym> language independent) source code, and could drive a "compiler" that would translate (encode) a source back into the internal object structure.
Are you suggesting we use an existing language and parser, or invent a new one? If the former, which one?
Essentially, what I am suggesting would be to add a layer between people and the existing XML interface, where there is a 1:1 relationship between each "source code construct" and each "object structure construct".
ftp | /--->Encoder-->\ fs |Source- | --XML--ZOPE etc | Code \<---Decoder<--/ \ DTD/mapping/magic (vulgar localizations)
XML is that layer. Whatever you've invented would replace XML, which would serve no purpose in the above diagram.
In fact, this interface notion would be useful regardless of the "source" code, even XML. Maybe I am missing something, but it seems to me that the XML encode/decode interface is mostly (if not completely) done. The questions that I have are:
1. How well does the import/export function deal with 'partial' trees
It seems to me that this is important for working on a single ZOPE instance, or collection of instances, irrespective of the hierarchy from which they may have been selected.
It handles it, I believe.
2. Can the acquisition expectations (of an object) be stated, or explicitly encoded so that the encoding of an object more or less 'stands alone' (that is, acquisition expectations be identified by name so that any willing supplier of that name is acceptable.
This is probably currently a weak link because (from what I've seen, the XML representation is accomplishing the encoding of these dependencies by "nesting" the specs. IMO, the dependencies need to have explicit encoding rather than a "inclusive scoping" (akin to what we have in explicit transistors vs nested gates, or explicit gates vs nested chips, in a circuit).
Hmm, perhaps you could make a specific proposal? The design goal of acquisition was to make it transparent. If instead we take it in a direction where people have to use different syntax, and know it is there, then that would take it out of the hands of non-programmers. In summary, I think it is doubtful that you could invent a language that would improve on XML and gain wide acceptance. Perhaps it's worth a shot, so the best I can say is, good luck! --Paul
Hi, Paul Everitt wrote:
Two observations:
1) Does the XML Export accomplish roughly what you want? Namely, a mostly-text representation that can be round-tripped.
Probably good enough... I haven't had enough experience reading code in this way yet to really say for sure.
2) What do you do when your source can also have state? That is, your source is stored as a rich object in a database, and can have run-time settings (permissions, properties, etc.). Uou are asking for both your source *and* your database to exhibit the above.
Thus, can you name a database system that doesn't "get your goat"?
;-) I guess that what I am asking for is to have a full decodable encoding of whatever is "current"... If the XML is too obscure (in detail and nesting) then we need something to abstract things to a higher level... I sort of think of XML as being the "assembly language" representation... need a "higher level" language... sort of byte code vs Python).
In reading Paul's reply, I am reminded of what /proc does... (To my knowledge) nothing in /proc is a "real" file, but open(), read() etc don't seem to notice that. Likewise, the "source" interface to ZOPE could have an ftp (or even 'mountable filesystem') "appearance" for the
I'd love for someone to write a mountable filesystem for Zope, but I'm not sure how much it would help. Zope has a lot of semantics that stat doesn't cover.
Right, and these semantics could (possibly) be presented in the form of pre/post contract conditions for the explicit purpose of correctly hooking the imported object into the database "circuit" correctly. (More on this below).
The problem here isn't how to get the object. The problem is how to express the object once it is gotten in a way that old-style, file-oriented programs and protocols (e.g. Emacs and ftp) can still participate.
Well, that's what the additional specifications do... If these can all be gathered together in one area, then one can safely "ignore" them (e.g. like a mail header is generally "hidden" from the e-mail user unless a "display headers" setting is enabled), sort of pattern it after a mail message perhaps: <requirements>...</requirements> <body>...</body> If you have an integrated editor, then the <requirements> which has acquisition linkage, etc, would be "hidden", and only the <body> would be modifyable.
The problem, and the goat :^), are as much with all the editors in the world and their protocols as it is with Zope. I could easily change your goat to say "All editors and IDEs should work with the web object model." :^)
Yes, that would be a logical interface to define, for those wishing to be "integrated".
navigational/organizational aspects (object hierarchy). The contents of each object (IMO) *must* have a source code representation, which is fully
Again, do you make the same demand of Oracle/MySQL? If so, how do they accomplish it?
Actually, yes... What they are missing natively, we are adding what we feel we need (metadata) to manage our diverse environment... Pretty basic at this point (not even capable of representing all of the stuff that we capture for eventual contents). Actually, Oracle export files contain everything I need to recreate the database... So, relative to Oracle, things are cool, IMO... I can get out what I put in... Would I like improvements over exp? Absolutely! But, it is mostly adequate (looses comments and other useful stuff).
capable of representing all aspects of the object, but in a "conventional" format (not XML).
Please name the format you're thinking of. If you ask nearly anyone on this list, "Name the standard for clear-text encoding of dynamic content", I imagine XML would get the most votes. I personally can't think of many other choices. Perhaps we could use the Python text-based pickle format. :^)
I am not thinking of a specific format, per se... Sort of had in mind that the existing XML (with addition attribution for linkage,etc) would serve as the "assembly language" representation. Then the "higher level" representation would allow for a more "conventional" representation. Think of how (well formed) byte code and Python source map to one another. There's lots more stuff in the byte code than appears in the Python source.
The fact that XML is capable of representing everything in ZOPE, it seems that a suitable set of DTD/mapping/magic would render (decode) any ZOPE object into a 'suitable' (<retronym>human</retronym> language independent) source code, and could drive a "compiler" that would translate (encode) a source back into the internal object structure.
Are you suggesting we use an existing language and parser, or invent a new one? If the former, which one?
Probably a new one that is based on being DTD driven (a DTD that drives the translation between XML and the target, not the XML DTD).
Essentially, what I am suggesting would be to add a layer between people and the existing XML interface, where there is a 1:1 relationship between each "source code construct" and each "object structure construct".
ftp | /--->Encoder-->\ fs |Source- | --XML--ZOPE etc | Code \<---Decoder<--/ \ DTD/mapping/magic (vulgar localizations)
XML is that layer. Whatever you've invented would replace XML, which would serve no purpose in the above diagram.
Not replace, augment... Much as Python is an abstraction over byte code (which is XML in this context).
In fact, this interface notion would be useful regardless of the "source" code, even XML. Maybe I am missing something, but it seems to me that the XML encode/decode interface is mostly (if not completely) done. The questions that I have are:
1. How well does the import/export function deal with 'partial' trees
It seems to me that this is important for working on a single ZOPE instance, or collection of instances, irrespective of the hierarchy from which they may have been selected.
It handles it, I believe.
Not surprised ;-)
2. Can the acquisition expectations (of an object) be stated, or explicitly encoded so that the encoding of an object more or less 'stands alone' (that is, acquisition expectations be identified by name so that any willing supplier of that name is acceptable.
This is probably currently a weak link because (from what I've seen, the XML representation is accomplishing the encoding of these dependencies by "nesting" the specs. IMO, the dependencies need to have explicit encoding rather than a "inclusive scoping" (akin to what we have in explicit transistors vs nested gates, or explicit gates vs nested chips, in a circuit).
Hmm, perhaps you could make a specific proposal? The design goal of acquisition was to make it transparent. If instead we take it in a direction where people have to use different syntax, and know it is there, then that would take it out of the hands of non-programmers.
Right, just as the scoping rules of Python are transparent in Python, but explicit in byte code... I realize that I'm arguing for a backward "detailing" (less abstract) to the rest of the argument, but this is probably necessary since someone has to be "explicit"... Also, this information could be carried in the <requirements> specification that is not seen by an IDE or an "aware" editor... Sort of along the "resource fork" idea? Separate, but together. The <body> may be broken to useless without its <requirements> "fork".
In summary, I think it is doubtful that you could invent a language that would improve on XML and gain wide acceptance. Perhaps it's worth a shot, so the best I can say is, good luck!
At the level of XML, I agree... However, for what I am suggesting, the point is, no one would necessarily have to agree on "the language"... only on the mechanism for specifying a language. I'd have the ability to create custom "shorthand" languages that are easily mapped into the "virtual ZOPE machine language".. Even a "graphical" language. (A case in point... I developed a "finite state machine language" that allowed developers to use either a graphical drawing tool or a source code interchangably, either way at any time. I had to make sure that the "language" and the "drawing tool" were both capable of fully representing my internal representation (which included where the "bubbles" and "arcs" were placed). Maintenance could be done by either "programming" or "drawing" modes. Also, if I had my special language based in English, and someone wanted to make a Spanish/Italian/Esperanto version of the same language (transliteration of a grammar rather than a different grammar), all that would be needed is the mappings. The semantic processing to/from XML/target would remain constant. Presently, I'm "running for the ZOPE bus" that has temporarily stopped beside the curb (busily documenting, right?) while waiting for those running along side trying to catch up.
--Paul
_______________________________________________
-- Cheers, --ldl ----------------------------------------------------------------------------- LD Landis ldl@HealthPartners.Com N0YRQ Voice 612/883-5511 Fax 612/883-6363 HealthPartners, 8100 34th Avenue So, PO Box 1309, Minneapolis, MN 55440-1309 Shape your life not from your memories, but from your hopes. (Borrowed) -----------------------------------------------------------------------------
participants (4)
-
flight＠mathi.uni-heidelberg.de -
LD Landis -
Paul Everitt -
Paul Prescod