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

[Jim Fulton]

Andreas Jung wrote:
> 
> 
> --On Sonntag, 7. September 2003 8:27 Uhr -0400 Stephan Richter 
> <srichter at cosmos.phy.tufts.edu> wrote:
> 
> 
>>
>> You make a false assumption here. The script support is **not** for
>> programmers, but for **scripters**. We do not want to go back to the PHP,
>> but  yet we have to ask ourselves why PHP is so successful. We have
>> thought about  this a bit and noticed that sometimes quick and dirty is
>> what you want to do  or the only thing someone starting with programming
>> knows how to do.
> 
> 
> Programmer or scripter...it does make a difference.

Yes!


 > Scripting support inside templates leads to unmaintainable code and unmaintainable sites.

For simple code and sites, I don't think that that is the case.
I suspect a profusion of Python scripts can be as bad or worse.

For non-simple code and sites, you are right.  The scripter doesn't build
these.  The scripter does somple things quickly. They get *lots* of value
by doing so.



 > In the
> current
> situtation with Zope2/CMF/Plone scripts are forced to separate content and
> logic (although ZPT allows to bring some logic into templates).

Right and the separation is cleaner with the component development model.


 > From my
> view
> as a programmer it is a nightmare to watch for related code in 
> PythonScripts
> *and* templates.

I can read this two ways. The obvious reading is that separation of code
between templates and scripts makes things harder to follow. I don't
think that this is what you meant. ;)

But I'll note that abstraction has a price. Separating code and presentation
is cleaner, *but* it makes it harder to unserstand the individual pieces.
You can't understand the the dynamic logic of the template without seeing
the code it calls. Similarly, the code often doesn't make sense if you
don't see what it's being used for. The code will be easier to understand
if it's in one place.  In general, I find that abstraction makes things
individually harder to understand. Abstraction pays off when things get
complex. Abstraction can make complex software easier to unserstand on whole.
I'm usually willing to trade off understandability of individual pieces to
make the over all system easier to reason about.  For simple systems, the
trade off isn't worth it.


 > Mixing Python and ZPT does not make things easier during
> the development and maintenance of a site.

That depends on the site.  I'd bet a buck ($1 :) that the vast majority
of people who use Zope build extremely simple one-off sites. For them,
the ability to get things done in a very quick and dirty way is a big win.

I think what we need to do is provide a migration path to developing
more complex applications for those who need it. That path should include
leading some new techniques as needed.

 > Ok...you could forbid your
> template designers and scripters to use scripts inside templates but such
> a measure is hard to enforce and it is not good for working together in 
> a project..

In Zope 3, I'm making a pretty clear distinction between scripting and development.
There will be different tools for these two activities.

By design, the tools for scriptors won't support development. For example, you won't
be able to use a templates page (dynamic pages) as "methods". In Zope 2, you could
create a ZPT page and acquire it by various objects. the template can display whatever
object it is acquired by, by using the "here" variable as the source of it's data.
In Zope 3, you won't be able to do that.  Templates pages don't have a "here" (or a
"context") variable. They only have "container". At the point where someone wants to
create a template for displaying many different objects, they want to create software
and need to switch to development mode.

Similarly, the tools for developers will support a more disciplined approach.  There won't
be a scipt tag. They'll be encouraged to put their Python code in modules.

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