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

Alan Capesius wrote:

The point here is the programmer mentality. Alot of people that work with the Web are not programmers and frankly, scripting pushes their limits. Dependence on Python limits the market.

I don't think the problem there is python. It's the names used in the Zope implementation. Currently, in order to get just about anything cool done in DTML, you have to stick in little bits of python code. I wouldn't mind that except that it requires you to know the names Zope uses behind the scenes, many of which are quite bizarre and IMHO not appropriate for people just trying to do simple web scripting. For example: the "_" variable -- why on earth couldn't it have a name that actually means something?? Another example: bobobase_modification_time - what the hell is a bobobase? Does anyone really care that zope evolved out of an earlier project called bobo? No. It would be easier to understand and remember if it was something like zope_modification_time or ZODB_modification_time. Even something like ObjectValues could be a bit friendlier - I'd call it something like Contents.

... The Open Source, Linux and Python communities are very insular. Probably a result of the anti-windows rhetoric tossed around so much.

I've found that the python community, at least as represented on comp.lang.python, is one of the friendliest on the net, and we really don't waste a lot of time bashing other languages (although python programmers almost universally share a dislike of Perl's messy syntax); and there's very, very little anti-Windows rhetoric on there. -- ................... paul winkler .................... custom calendars & printing: http://www.calendargalaxy.com A member of ARMS: http://www.reacharms.com home page: http://www.slinkp.com

-----Original Message----- From: zope-admin@zope.org [mailto:zope-admin@zope.org]On Behalf Of Luciano Ramalho But you should try PythonScripts. The use of PythonScripts will greatly simplify your DTML coding efforts. And Python's syntax is much easier to learn and read than DTML.

I'll have to take a look.

If what you want is more DTML tags to code your logic, then I couldn't disagree more. Whenever I pitch Zope, I use the fact that DTML has very few tags as a strong selling point. DTML could be even simpler, in my opinion, to really encourage separation between logic and presentation. ... Again, you really seem to like mixing logic with presentation (SQL and HTML). This can only be good if everyone responsible for maintaining a site is knows and likes both SQL and HTML. I find this combination a rare.

Not logical tags, but common functions to get rid of the convoluted syntax requirements. The separation of logic and presentation is a valid point, but not everyone uses the product in two camps. In my case, I do both. If you are correct and I am a rarity, then I'll concede the point.

I much prefer my_string[:3], my_string[2:], my_string[2:5] than having to remember the names and parameters of three diferent functions. On the

Good, good. But now try to find a ready reference to this kind of syntax and implementing it under Zope without learning Python first and you will see the fundamental problem a newbie to Zope encounters.

Hello all, Alan recently said:

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.

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.

Well, I am not a python-knowing person either, but I realize several things. Zope IMHO is a big python hack. Its a nice one, but its still a hack. No offense DC. I have the feeling that in one of my purely DTML coded pages, 30 lines is actually taking a multiplied value of that in the python that DTML mimicks. Doing it in DTML constantly is stupid when a python script can do the job. You'll see the differnce I think when your website is being pounded away by a high ratio of clients to server power. I'm just learning python now and I already notice a difference. You're probably just from the publishing world like me and happen to have to do it yourself. I agree with you about the documentation. It could be better, but the again, it kinda expects you to have aa developers mindeset. The web-world is becoming very cross-oriented and there are alot of non-developers trying to script with abysmal results. Its time to learn the language. Also keep in mind that GPLdom is not driven the way you would commercially. You work too much in the corporate world to see it. I'd like to see commercially driven documentation by people who make it their profession to talk about it from an outside perspective. Root of the truth is, if Zope was setup that way, it'd be a Microsoft product by now. Better keep it the way it is so people with a devotion to the functionality rather than the develop:sell ratio. I am quite happy to see DC working for the CoreSession and extending the WebDav. It's supposed to be a publishing solution, and its just that. Use of DTML is better off for only massaging the output into stylization instead of building core logic. Its not fair to ask a product to become better to make up for your lack of knowledge. Its just unfortunate that I spend so much time treading water with Zope, but once I picked up a python book, it's all becoming clearer. my half cent, Paz