[Zope3-dev] Re: Zope 3 Newsletter: Issue 10

[Jim Fulton]

Jeffrey P Shell wrote:
> On Friday, September 5, 2003, at 01:10  PM, Paul Winkler wrote:
> 
>> On Fri, Sep 05, 2003 at 09:46:52AM -0400, Gary Poster wrote:
>>
>>>   Python <script> support in TAL
>>
>>
>> I'm not sure whether to be overjoyed or very afraid :-)
> 
> 
> I'm very very afraid.

Don't be. :)

> This is one of the features about Zope that I can sell over and over 
> again - 'HTML is HTML and SQL is SQL and code is code is code, and never 
> should they meet.'  ZPT in Zope 2 brings an insane amount of joy to my 
> life.

This is still the prefered *development* model.

In fact, the <script> tags are not available for templates used for
development. They are only available for templated pages (active
content).  The script tags are for the scripter, which is a different
audience than the developer.

> I hope all of these things are add-ons.  And I hope they are add-ons 
> which cause painful physical electrical shocks upon using :).
> 
> 
> Zope 3 delights and terrifies me.  And adding 'script' and 'sql' support 
> to page templates doesn't help me deal with my concerns about some of my 
> sites and applications. 

Huh? Why said anything about adding aql support to page templates?

What are your concerns and how does the script tag affect them?

 > I think focus could be better spent on lowering
> the bar of entry for Zope 2 'script+template+sql method' developers than 
> PHP developers.

The PHP style of development is popular and useful for scripters.
We aren't going to support it for developers. We are putting lots
opf focus on developers in Zope 3, but scripers are people too. ;)

> I'm delighted because I find myself doing a lot of 
> 'component-architecture-style' development for Zope 2 now, and know that 
> there are many places where I'm jumping through hoops to achieve my 
> results.  And there are times when I actually wish I had ZCML in order 
> to replace a single registration component for a single customer instead 
> of having to hack it into the Python code.
> 
> But - the simple things of Zope 2, easy page templates and python 
> scripts acting as glue between 'front end' pages and back end components 
> seems terribly difficult. 

I'm not surprised, since most of the focus to date has been one developers
and not scripters. It's time we put some more emphasis on the scripters.
This is a great time to provide input.

For starters, I'd like to better understand what you find difficult.




> We've already decided that a site like Park 
> City Mountain Resort <http://www.pcski.com/> will just stay in Zope 2 
> land forever.  It doesn't require much in the way of dynamic content, 
> most of its pages are managed by non-Zope savvy users using Dreamweaver 
> (we rewrite DTML and Page Templates on the way in and out to make them 
> happy in the DW environment).  I have absolutely on idea how such a site 
> would work in Zope 3.  It's the kind of site where there is occasional 
> dynamic bits that exist out in content space with some supporting Python 
> Scripts to massage data coming into the pages, or to respond to a form 
> by passing it off to a lower level component. 

Well, there are content-space page templates and DTML in Zope 3. It's not
clear how things would be any different in Zope 3.

 > If I could replace the
> Python Scripts that massage data with a persistent module, I don't even 
> know how to address that module in public-space page templates in Zope 
> 3. 

Well, we need to decide that. Here are some thoughts.  There are two basic
styles of handling forms posts:

1. Post to a template (e.g. ZPT) that calls the necessary Python code.
    This is my preference.

2. Post to a bit of Python code that then calls the template. In this case,
    the Python code has to have a URL.

If we had Zope 2-style "script python", things would work the way they
do now, for better or worse.

If a form is posted to a template, then you could do the form processing
in one or more script tags.

If we had content-space modules, I would expect them to be traversable.
You'd traverse a module to get at one of it's methods.  If you wanted to
call a method from a template, you'd use a path expression like:
"container/themodulename/thementhodname" or, in a python expression:
"python: container[themodulename].themethodname(...)".

If the form is posted to the python code, then you'd use a URL like:
themodulename/thementhodname


 > The Python Scripts that respond to form input...well, it sounds like
> the Python Scripts that have been batted around for public-space Zope 3 
> will be able to handle that job (read form data, validate it, report 
> errors on one page if validation fails, save data on success and move to 
> next page).

Right

> Another situation is - I have an e-Commerce customer who manages his 
> pages himself.  Among these pages are a couple of dynamic pages (not 
> including the shopping cart) - the standard template (of course), and 
> pages that list products in a category and available inventory items for 
> a product.  Those two pages are backed by something that should be 
> replaced with a powerful view component, because it deals with 
> traversing a category tree defined in an RDBMS table (ugh) and 
> pre-loading a lot of data for the category or product in question.  The 
> customer sees those pages along side his pages which are basically 
> static.  He can edit the dynamic ones, and generally knows how to avoid 
> blowing up TAL.  He also has applied edits to the shopping cart/checkout 
> pages - again, avoiding the dynamic bits while adding his own text and 
> styles to other parts of the page.  He does this all in Dreamweaver.  I 
> have absolutely no idea how I could give him a site that behaved this 
> way in Zope 3 - are all of his fairly static pages in the public space 
> along side the dynamic pages?  How do they interact with their 
> traverer/loader component?  Are they all in some weird '++etc++' 
> package?  How do I give him access to that via FTP?  Will all the pages 
> list and look like he expects?  Do I have to tell him to put '@@' in all 
> of his urls? ('@@faq.html' even though faq.html is really a static page?)

All of this really depends on the approach taken.  If all of the pages
are in content space, then things will work as they do now.

Alternatively, the pages (or maybe the just the dynamic ones) are in
site-development folders.  As far as the dreamweaver user knows, these are
just folders. They can edit the pages in them, using FTP, or WebDAV
just like thet can edit pages elsewhere. These folders are subfolders
of ++etc++site.

> These are just the concerns that are mounting on my side.  Again - there 
> are a lot of situations where I'm happy about what I should be able to 
> do with Zope 3.  But there are a lot of places where I just don't know 
> how I can do a lot of I've been doing for the past couple of years. 

In some cases, it's because you haven't learned what's already there. In
other cases, there are more things we need. This is a good time to provide
input.

 > As
> a Zope 2 user, I hope I'm higher up on the "make happy with Zope 3 
> development" list than a PHP user.

The choice isn't between you and the PHP user. There are a number of
users I want to serve with Zope 3. They are all important. Two of them
are:

- The site developer

- The site scripter

These are very different users with very different needs, skills, and
expectations. The same choices aren't going to be right for both.

When someone starts using Zope, they will probably start as a scripter.
Hopefully, we'll make it easy for them to quickly solve problems and get
lots of early success. If and when their needs go beyond what they can do
with scripting, they will have a choice:

- Learn how to to development in Zope 3. Development is more disciplined
   than scripting. The discipline is necessary to handle the increasing
   complexity of their applications.  They will need to learn some new
   concepts and techniques. We'll make this transition as clean as possible.

- They might just decide to hire a Zope developer to take them to the
   next step.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (703) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org