[Zope] Zope and Frontier Comparison

[Michael Bernstein]

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