[Zope] Editing DTML Methods with Emacs ?

[LD Landis]

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)
-----------------------------------------------------------------------------