[Zope3-dev] Flexibility

[Jeffrey P Shell]

On 3/26/02 4:47 AM, "Tres Seaver" <tseaver@zope.com> wrote:
> 
> Let's "review the bidding," please:
> 
> - Zope3, as constituted so far, is *explicitly* for developers,
>   not for content managers;  Zope3 is supposed to provide the
>   platform on which developers build the applications used by
>   content managers.

And - I hope - Content Managers is just one potential vertical market.
There are things to do on the web besides content management, although CM is
a big one.  I tried writing a very business oriented project/customer
tracking application using the CMF, and many of the CMF features got in the
way as much (or more) than they helped.  The application was never finished.
When it works, it works great.  But I spent as much time deprogramming
content and membership specific parts out of the CMF as I did making my
business objects (tasks, customers, contacts, projects), views, and workflow
agents.  I liked the component-ish feel of the CMF, but the content specific
features got in my way *so* much that I was seriously considering other
platform options for future Cue Media work in this area.

In our recent customer driven work, even the content management based sites,
we've been growing a simple framework in house, because it was easier than
deprogramming unwanted features for very simple systems.  The CMF is pretty
good software (and we're likely to use it in an upcoming project if we win
the bid), but I would really like to keep the more vertical aspects of
content management separate from the Zope core.

> - Many of Zope2's notorious problems are a result of its inability
>   to decide who its primary audience is;  Zope3 is avoiding that
>   mistake firmly, for now.

I'm hopeful for this.  If the architecture is done well enough, Zope3 should
be easier to configure for different audiences.

> - The "simple script" development paradigm of Python is very much
>   like the "just a few PageTemplates and a PythonScript" development
>   model of Zope2:  both work, but bang up against their intrinsic
>   limitations when pushed too far.  Zope3 is not *yet* able to
>   support this model, but it doesn't support *any* TTW development
>   yet.  I think we can assume that the moral equivalent of the
>   small TTW app will be at least as easy in Zope3;  but it is
>   *not* more important than getting the security architecture
>   right, for instance.

I hope the small TTW app model remains about as easy as it is today.  When I
was telling a coworker about Zope3, he balked.  He had been working on a web
site with very few things that could be componentized - each page was
unique.  It was all built out of DTML pages and SQL Methods, with heavy
design work.  

I think the "templates and simple scripts" site, especially one that won't
grow, is still pretty common.  In this case, even if everything was
componentized, the customer was changing and adding requirements enough that
there would be very little code that wasn't under constant change.  Being
able to respond quickly - while giving us major headaches - went over very
well with the customer.  I agree that it should be a lower focus point right
now, but it is an appreciated feature.

And also - if the component architecture is done right, this feature should
be more powerful because being able to add and script third party components
should be easier than it is now, since authors of those components should
have a better guide to developing them in a common way (and since
"management screen" based methods should be kept outside of the core
component).

[SNIP]

-- 
Jeffrey P Shell 
www.cuemedia.com