[Zope] is DTML a www standard?

[Casey Duncan]

Alan Capesius wrote:
> 
> > -----Original Message-----
> > 2) "Is DTML a web standard?"
> >    Answer: This question is somewhat misleading.  DTML is used on the
> >    Zope server to dynamically render HTML back to the client.  Someone
> >    viewing a Zope webpage in whatever web browser they use will NEVER
> >    see any of your DTML, and the browser doesn't need to know anything
> >
> 
> This is a very good point.
> Cold Fusion uses proprietary tags too, but no one expects them to be a web
> standard.
> 
> I'd think that the confusion lies in the use of the DTML moniker. It's so
> similar to HTML that people assume it is a web standard, I know I was
> looking for other standards references and sources when I started with Zope.
> 
> I was referred to Zope by a colleague who was learning Python. But, the
> majority (99.9%) of my Zope work is done in DTML. I have NO external methods
> on my site and no desire to spend time learning Python syntax. I have enough
> to do with my VBScript, JavaScript, C++ work. DTML allows me to do rapid
> web-to-SQL work without the convoluted and MS-centric use of the IIS APIs
> and ActiveX and is well worth the investment.
> 
> Zope and DTML syntax and usage is way too tied to python syntax to make a
> good standard anyway. I believe that the syntax derived from python coding
> is a fundamental limiting factor for Zope growth. A friendlier and more
> complete DTML tag structure would accellerate Zope aceptance by those that
> do not come from a Python background. Since Zope grew from Python and is
> primarily supported by Python pundits, I wouldn't expect to see much along
> these lines.

Zope page templates are attempting to do just that by making a Zope
scripting language that is standards compliant, ala XHTML. I myself have
not used them much, but I hear they are addicting.
 
> Documentation out of the box is improving, but many products are documented
> with a "look at the code" mentality. This is an "old boys club" mindset that
> says that once I know something, you should know it too.

This is just an illustration of the rule, coding is easy, documentation
is hard. What should I spend my time on, creating documentation (which
is boring for most programmers) or coding new features or hunting bugs
(which is/can be fun)? Many developers choose the latter, especially in
the open-source arena where there are little or no corporate
requirements. Also, many programmers are much better at writing code
than readable English.

My friend, one of the greatest contributions someone can make to a
project is documentation, and you don't have to be a programmer. Feel
free to pitch in!

> 
> As with any other system, designing it for ease of use it what makes it
> popular. Zope development efforts seem to focus on the Python technology
> rather than Zope itself. What I have seen of Cold Fusion (admittedly
> limited) focuses on what you can do with Cold Fusion, not what language Cold
> Fusion is written in.

I would disagree. Many of the major initiatives in Zope right now: CMF,
Page Templates, etc are focused around content management and user
interface.
> 
> It would seem to me that a good direction for Zope to move would be to do a
> few things that would significantly enhance development time:
> 
> 1) Create an expand DTML tag library offering functions common to most
> langauges and comparable to competitive systems. Remove the reliance on
> python syntax with basic functions like strlen() and substring()

Again I would recommend looking at ZPT.
> 
> 2) Simplify the SQL interface of DTML methods by creating a new method type
> that integrates ZSQL Method and a DTML Method into a single entity for doing
> simple single query-and-report operations.

I see this being more complex, not simpler. To me one complex DTML
method is much worse than 3 or 4 simple DTML/SQL methods,
documents/scripts.
> 
> 3) Shift the focus of Zope promotion and development to be Zope-centric with
> less reliance on Python-centric solutions. This would help to remove the
> barrier to use created by the need to learn Python coding. The result would
> be the opening of Zope to a non-programmer community (like alot of the Cold
> Fusion community) and a reduction in resistance to Zope development by
> management who is hesistant to bring yet another programming language into
> their shop (a concept I've seen often in this list). Support for external
> methods would still be maintained.

I agree there are ways to make Zope more programmable without
programming. However, I think you are making Python seem a lot harder
than it is. It is one of the easiest languages to learn and work with.
Especially now that we have TTW Python scripts built-in to Zope.
> 
> 4) Redesign the Zope.org site to focus on how to use Zope to get things
> done. The current focus (on the home page) is a management overview of the
> Zope Concept that offers little real application content. The Learn Zope and
> Introduction and Tours offer zero information to the person who is actually
> going to use the product. The "Hello World" example is about it, expanding
> that concept a hundredfold would do the trick. Kind of a Do this to get this
> example library.

I agree, a lot could be done to improve Zope.org. I think the single
greatest thing that DC could do, is open it up so that Zopistas in the
community could contribute directly to its development.
> 
> 5) Expand the focus to embrace the Win32 market. Now, admittedly I am biased
> here, as a Win32 programmer. But the userbase is there and Zope easily blows
> away any learning curve Microsoft would require to learn their products. It
> would seem that converting the enemy's minions would be better than fighting
> them. "Zope: converting the enemy's minions" I like that :)
> 

I believe this is happening. Zope just needs to reach a critical mass of
users to get truely "embraced". Once that happens, I think all hell will
break loose.

> Oh, and P.S...
> 
> 6) Personal pet peeve - Improve handling of whitespace in DTML docs to
> reduce page sizes. Basic starting point: suppress all blank areas output
> between rendered DTML tags when no content is present.

Good suggestion. DTML can create some fugly looking HTML output.
> 
> - Alan

-- 
| Casey Duncan
| Kaivo, Inc.
| cduncan@kaivo.com
`------------------>