[ZWeb] testimonials

[Brad Allen]

>For the middle content well of version 3 i thought it would be nice 
>to have some catchy testimonials somewhere. I remember seeing 
>somewhere "Zope is what Cold Fusion wants to be". In a marketing 
>sense, these quick little blurbs can be very effective. Can anyone 
>else think of testimonials like this or get some more? Please 
>include the speakers name if possible, but don't sweat it if you 
>can't.

I've been working on some Zope 3 marketing text, but haven't finished 
and haven't
figured out where to put it. It contains some long quoted 
testimonials which I imagined
might go on the sidebar alongside an FAQ. This could be a subject-oriented FAQ
in which one of the categories would be something like "Zope 3 is not 
your daddy's Zope",
or "Forget What You Learned About Zope 2"...I don't know...it's still 
at a brainstorming
stage...

Here's what I have so far (thanks to Michael Bernstein at the recent sprint for
some of his suggested words).






Q: I'm not a fan of Zope 2. Newer frameworks such as Turbogears and
Django seem much more Pythonic. Why should I look at Zope 3?

A: Zope 3 is a complete rethink with a component-based architecture. Legacy
limitations and shortcomings have been removed. You'll find it worthwhile to
to take a little time to learn about the benefits of leveraging the years of
development and real world experience that grew into Zope 3.

Zope 3 scales both up and down. It's usable for small, simple websites, as well
as huge complex enterprise applications and content management systems.

Django and Turbogears currently still have an advantage when it comes to rapid
development of straightforward web-applications, but Zope 3's small additional
learning curve at the entry-level quickly repays itself when your needs become
more complex or when you need to reuse components for other apps.

In addition to the usual feature set of web app frameworks, Zope 3 has a few
important extras:

	Object Database (ZODB): no need for ORM; no impedance mismatch mapping
		from RDBM to classes and objects. You can still use 
SQL if you prefer.
	Interfaces and Adapters: glue together loose collections of components
	Internationalization (i18n) and localization (l10n):
		Convenient support for multiple languages
	Extensive testing support
		Thousands of internal tests that are run by core developers
		Testing features to run against your own web app
	Deprecation Model
		Allows graceful retirement of old APIs as the Zope evolves
	Strong Configuration Model
		ZCML is a simple and powerful XML dialect for 
enabling/disabling
			features for a Zope 3 instance
	Security Model
		Pluggable Authentication (LDAP, etc.)
		Authorization controls for various parts of your app, based on
			roles or individual users



Btw, Zope 2 doesn't necessarily suck anymore. It's the most widely deployed
Python web framework, with many large scale successful web applications in
use today. Professional Zope 2 developers generally avoid problematic
DTML designs and don't do "through the web" (TTW) development anymore.
Also, Zope 2 developers increasingly use the FIVE interface to utilize
Zope 3 features inside the Zope 2 environment, as a prelude to forward
migration.


Q: Ok, tell me more about this component architecture idea.

A: Here is a quote from Stephan Richter, author of the Zope 3 
Developer's Guide:

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

When the Component Architecture for Zope was first thought about, it was
intended as an extension to Zope 2, not a replacement as it developed 
to become.
The issue was that the existing Zope 2 API was too bloated and inconsistent,
due to constant feature additions, bug fixes and coding inconsistencies.
The extremely bad practice of "monkey patching" became a normality among
developers to overcome the limitations of the API and fix bugs. Monkey patching
is a method of overwriting library functions and class methods after importing
them, which is a powerful, but dangerous, side effect of 
loosely-typed scripting
languages.

Another motivation was to incorporate the lessons learned from consulting jobs
and building large Web applications, which demonstrated the practical limits
of simple object inheritance. The need for a more loosely-connected 
architecture
arose with many objects having rather tiny interfaces in contrast to Zope 2's
few, large objects. This type of framework would also drastically reduce the
learning curve, since a developer would need to learn fewer APIs to 
accomplish a
given task.

All these requirements pointed to a component-oriented framework that is now
known as the "Component Architecture" of Zope 3. Many large software projects
have already turned to component-based systems. Some of the better-known
projects include:
	*	COM (Microsoft's Object Model)
	*	Corba (Open source object communication protocol)
	*	KParts (from the KDE project)
	*	Mozilla API (it is some ways very similar to Zope 3's CA)
	*	JMX (Sun's Java Management Extensions manages Beans)
However, while Zope 3 has many similarities with the above architectures,
thanks to Python certain flexibilities are possible that compiled languages
do not allow.


				-- Stephan Richter, The Zope 3 Book

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Here's another quote about Zope 3

from http://cguardia.blogspot.com/2005/09/frameworks-magaframeworks-and.html

At 12:33 PM on 5/22/2005, Kevin Smith said...
It would be a shame to discard Zope3 so easily.

Zope3's strength isn't to hack out a simple use case in 20 minutes (or in 2
minutes if you've seen the latest Zero To Rails screencast). Z3's 
strength is to
leverage best programming practices into building enterprise-class web sites.

To understand these best-practices, I needed to buy both Z3 books (a spendy but
worthwhile investment).

To experience the fruits of these best-practices, imagine you have a client.
You're building them a site using your favorite framework. They want 
an intranet
with a blog and a wiki. Comments would be nice. How about categories? Oh and
let's make it multi-user, but we don't want our interns to publish without
review. Make the textfield support ReST and Textile. Swap out various field
widgets for even better ones. Let's use LDAP. How about subscribers to blog
entries? Then package it up as a site to redploy for the sales division to run
in the same process. Let's make a customer extranet, it'll need to be 
skinnable.
Hey, don't forget about the European partners, the site needs
internationalization. What about testing and documentation. Oh and yeah, the
client has just a few more minor suggestions...

No problem with Zope3.

In my experience, building the initial program is easy, changing it is a
nightmare. The interdisconnectedness of Z3's component architecture allows the
program to pleasantly evolve.

Instead of adapting the business model to the needs of the website, the website
adapts to the needs of the business model.

This is the power of Zope3.



-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=






What are the strengths of Zope 3 as a web development platform?

	Scaleability
		ZEO - <need content here>
		Extensive testing framework
		Component Model lends itself to problems of scaleability

	Component model:
		The component model allows for high reusability of 
Python packages.
		Component-based applications lack fragility, support 
agile development
		Especially useful for organization that produce many 
sites requiring
			common components
		Use of interfaces and adapters can replace 
inheritance in many cases


	Security:
		...?
		Common Security Certification

	Pluggable Authentication
		<need content here>

	Encourages Well-Organized Application Architecture
		ZCML configuration language. See ZCML FAQ


	Object Database
		ZODB is robust and mature
		No need for ORM, no impedance mismatch mapping RDBM to objects
		Generations tool supports refactoring of persistent 
objects as classes
			evolve

	Robust, mature template and macro engine
		ZPT and METAL

	Multithreaded or Asynchronous -- pick your poison
		Zserver is multithreaded
		Twisted Server is async


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

What are the deficiencies of Zope 3?

	There aren't a lot of components available for download yet, 
as compared
		with Zope 2.

	There is no AJAX stack--you will have to add your own. Fortunately, you
		can adapt existing Python AJAX libraries.





-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=










ZCML Questions

What are the benefits of ZCML?

A:	Separate configuration from application architecture
	Usable by non-Python sysadmins

Q: Why choose an XML-based syntax for configuration?
A: Parseable and manageable by non-Python apps and scripts


"""
Thoughts from Duncan McGreggor on the Zope3-Users mailing list:

About ZCML: it's kinda hard to get used to. I hated it at first. But it
makes more sense that most other ways of doing things... the problem is
that we've gotten used to mixing configuration and code. ZCML is the
quiet hero in this regard: it gives us the long-needed tool to separate
configuration from application. And if you think about it, this really
makes the most sense. If you've got a hundred clients that want to use
your product, each of those clients should only have to change
configurations, not the actual code itself.

Additionally, I really like the clean approach that z3 has as a result
of ZCML: if you haven't configured it, you aren't going to see it/use
it (as an end-user, I mean). This appeals to the security engineer in
me ;-) It also makes things wonderfully simple as far as
enabling/disabling features.

Back to your question: ZCML doesn't actually do anything -- z3 looks at
it to "know" what to do. So, in order for z3 to know about content
objects, custom views, resources like images, etc., you have to put it
in ZCML (well, for some things you can put it in python, too).

<snip>

ZCML is confusing at first because of the many features and the
conceptually different aspects of application configuration for which
it is responsible. To keep all of these straight, I ask myself
questions like:
* is this part of my code just purely content object?
* is this part application internals?
* is this part management UI related?
* is this part content presentation?
* is this part just look at feel (page structure and CSS)?

I tend to put each of those in their own areas or sub areas (read
"directories"). They each have different ZCML files; a top-level ZCML
file includes the ones from the next level down, etc. The best way to
come to term with this stuff (in my mind) is to jump in and start using
it, even if it doesn't make sense at first. Much will be revealed
simply trough the doing of it.

BTW, As a result of practices such as these, the z3 projects I have
worked on have been the conceptually best organized projects I've ever
been a part of.
 
	--Duncan McGreggor
"""