[Zope-dev] Fw: [Zope-dev] wygiwys

[Damian Morton]

----- Original Message ----- 
From: damien morton <morton@dennisinter.com>
To: Jeffrey Shell <Jeffrey@digicool.com>
Sent: Thursday, September 16, 1999 6:55 PM
Subject: Re: [Zope-dev] wygiwys



----- Original Message ----- 
From: Jeffrey Shell <Jeffrey@digicool.com>
> 
> If the community were to come up with something REALLY good, we'd be
> interested.  But there's a lot of difficulty matching the advanced
> philosphies of Zope (Acquisition, Security, and now ZClass based
> objects) and DTML (namespaces, syntax, general concepts) with just about
> any visual editor out there.  A _LOT_ of difficulty.  It would be a
> project of some serious effort, and we haven't seen anybody with enough
> initiative to come up with a plan of tackling this.
> 
> On the other hand, the new syntax is easier to work into smart
> (non-visual) editors like Alpha (and Emacs-ish editor on the Mac) with
> syntax completion and all that.  Some tags like the contributed dtml-let
> tag may have some difficulties in these environments that prefer to help
> keep code very neat by quoting all attributes (a good thing really),
> since the dtml-let tag behaves differently (ie,
> 
>  <dtml-let bob=uncle lu="aunt()" billy="'cousin'">
> 
> )


The basic problem is that most good html designers (as opposed to html hackers) are working with object oriented design tools. They whack this object there, set its properties, attach some behaviours, and away they go. They are working at the DOM level.

Many of the objections to integration object oriented html desitgn tools with programmer oriented tools such as zope arise from the fact that programmers like to work with the raw text of the html. But the raw text is just the transport layer. Whats really being handed around in a http transaction is DOM trees that happen to be represented as html.

If our work as programmers focussed less on whacking out html text and instead focussed on producing and consuming DOM nodes, then the integration between object oriented html design tools and out programming tools would become a lot easier. 

In fact, the a website as a whole could be viewed as a DOM structure, and there are many advantages to this. For example, if we assumed that our programs elemenst were functional DOM consumers and producers, you could eliminate much of the dynamic nature of a website. In my experince, there is a whole lot of stuff about a website that only changes slowly - it doesnt need to be re-created for every page view, only when the source data changes. If you could decompose a website into a kind of feedforward dataflow machine and add some intelligent caching, you would have a very efficient dynamic website. What would be needed for that would be for the programmed part of the website to conform to functional or dataflow programming - each module or function would take objects as input and would create or modify existsing objects. Might mesh well with the ZODB mechanism.


> And there's always problems with this perrenial favorite (dtml tags
> inside of HTML tags) -- 
> 
> <tr <dtml-if sequence-index-even>bgcolor="#c0c0c0"</dtml-if>>
> 
> And, well, a trying-to-be-SGML-complient editor that is doing all these
> wonderful things to help you (syntax hiliting, completion, dialog boxes
> with tag attributes) panics and jumps over these.
> 
> But situations like that aside, the new syntax is significantly easier
> to work with.  And with FTP and WebDAV integration, authoring outside of
> the management interface is made a little bit easier (but work still
> needs to be done in this area to help it along).
> 
> So, the dream lives on... :)
> 
> _______________________________________________
> Zope-Dev maillist  -  Zope-Dev@zope.org
> http://www.zope.org/mailman/listinfo/zope-dev
> 
> (To receive general Zope announcements, see:
> http://www.zope.org/mailman/listinfo/zope-announce
> 
> For non-developer, user-level issues, 
> zope@zope.org, http://www.zope.org/mailman/listinfo/zope )
>