[Zope] Editing DTML Methods with Emacs ?

[Paul Everitt]

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