Kam Cheung wrote:
Ok here goes for the stuff you've overlooked:
If you know that you want the header and footer inserted into every document and combined with bodytext, then all you have to do is define index_html in the site root like this:
<!--#var pageHeader--> <!--#var Bodytext--> <!--#var pageFooter-->
and just insert a Bodytext method or document into the various folders, with overriding pageHeaders and pageFooters where appropriate. You only need to place index_html into a folder when your template changes.
After this point you start to explain how frontier does this too, and how it's a pity that Zope doesn't do this, so I'll just skip that.
Hopefully, I got it right ... you are talking about treating a folder as a document, right? I thought of that too. While it works, it's not natural, at least to me. If you are talking about something else, please let me know. I really want to find it out -- after all, it's the whole point why I am here.
More or less. I look at a DTML Method as a view into the object hierarchy at various points. In many if not most cases, those views can be standardized and modularized (templates within templates). Thus, you can look at the content in a folder using the standard index_html, or you can define some new methods called txt_html for a lynx friendly view of the same content.
The point is, DTML documents and methods can be used to both hold content and act as templates, it's up to you to decide how you want to factor your sites functionality, layout, and content into the Zope object heirarchy.
(The following opinion is based on my understanding of your explanation, if I were wrong, you can ignore it)
My point is, the way how Frontier "FORCE" the template concept to the user is easier to learn for beginner.
Hmm, you may be right, but for me, the sudden freedom of defining a content and functionality framework that does not need to be forced into a filing system metaphor was very liberating. I understand that Frontier offers the same sort of freedom from filing systems, but it sounds (and I may be wrong here) as if it is constraining you to a template metaphor. While that may make the learning curve a bit less steep at the beginning, I find that solutions that do not have 'one right way' of accomplishing a task to be more congenial (note that there usually is a 'best way' even if there is no 'right way'). This does of course put more of a burden on the developer/designer to think through the Object-Oriented Analysis and Design of their application, but I don't see that as being a bad thing, especially since Zope makes it so easy to test changes through Versions, without requiring a staging server.
But keep in mind that I am not against Zope at all. I have been using it for just a few days, and I already love it. The web interface of it is, IMHO, 1 internet years ahead of Frontier!! Remote management of Frontier is next to non-existent. There's a lot more, however, trying to compare these two products is not a very productive thing to do. They can work with each other very nicely.
Sorry, I didn't mean to imply that you were criticizing Zope, and I hope you don't take my comments as criticism of Frontier. Frontier has it's own strengths in terms of content creation and management with it's outliner and integration of desktop application scripting, but Zopes design centers around web application design, deployment, and management. Some of those applications are content creation and management, but not all. Anyway, I for one am glad to have you and the other Frontier people here on this list, and I'm sure that the cross-pollination of ideas will benefit both communities, even as our platforms compete in certain areas. Co-opetition rules! Michael Bernstein