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

[Jeffrey P Shell]

On Sunday, September 7, 2003, at 07:46  AM, Jim Fulton wrote:

> 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.

Nothing ever stays simple for long.

> 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.

I like that we really separated the Scripter from the Developer - but 
there are certainly going to be a lot of situations where the two 
things cross over.  Is this going to make it harder for the developer 
to maintain code in 'scripterland' space?  I do a lot of my development 
wearing separate hats - sometimes it's focusing on core components, 
sometimes it's gluing the HTML and scripts together for the end-user 
experience.  I don't want to go through complicated hoops as a 
developer to make end user pages.  At the same time, I *don't* want 
quick and dirty.  In my experience, quick and dirty always leads to 
long and painful.  Yeah - the site is developed and deployed in two 
weeks, and then kicked and maintained and put up with for three more 
months until everything settles into a semi-refactored code base.

For the 'Developers who Script' - or even for people who are pure 
scripters that are working with developers - there should be something 
better than "Quick and *Dirty*" that satisfies a relative 
ease-of-development scenario.

> > 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).

'separate content and logic' is not quite the right term here.  Well, 
maybe it is with CMF/Plone.  But CMF/Plone hurts my brain anyways.

But there is a difference between display-oriented logic (conditionally 
showing a tag, or a row, higlighting even/odd rows in a result set, 
iterating over result sets, etc) and controller logic.  (pre-loading 
data, handling a form post).

> 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.

If they're doing quick one-off sites, the whole Zope framework is 
probably too much overhead for them.  Why do they need the component 
model?  Why do they need persistence?  Acquisition?  Why do they need 
the higher memory overhead that Zope incurs over a system like PHP?

PHP is quick and dirty because it's everywhere, most hosting providers 
support it already, and there are a trillion books about it.  It's also 
easy enough to configure and install in most places where it doesn't 
exist.  It does have a very low bar of entry - put a file in your 
public_html directory with a .php extension on it, and there you go.  
Zope is just not going to compete with that.

Zope is not appropriate at all for simple systems.  I think that if you 
want to just display a bulleted list of Merzbow items that you own, and 
maybe have a dynamic pithy tag-line on your home page, you're much 
better suited with something like SkunkWeb that has a much lower 
resource overhead.

We actually faced this issue a while ago, and were looking for an 
alternative to Zope for these 'small site applications' because Zope 
just does way more than was needed and put more resource demand than 
was needed.  (We stayed with Zope though - mostly for its development 
model, and for page templates, and python scripts, ironically enough).

> > 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'd bet against that.  Given that Zope is not particularly easy to set 
up (prior to Zope 2.7), install, configure with apache (virtual hosts), 
etc, I expect that by the time someone chooses to go through that 
process, they don't want to use Zope merely for "extremely simple 
one-off sites".  If they want extremely simple one off sites with code 
in the pages, there are a lot of competing technologies, just in the 
Python world alone, that would better satisfy their needs.

Again - see my point above about resource consumption, etc.  If people 
are willing to learn about the benefits of putting their HTML and 
Scripts into an object database, they're willing to learn why those 
should be separate.

Otherwise, we should just buy Spyce, call that Zope 3, and be done with 
it.

> 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.

There is no 'here' or 'context'?!  *sigh*.  So much to relearn...

> 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.

Sometimes, these two activities bleed over.  I appreciate the 
difference - really.  I just hope things aren't atmospherically 
different on the two sides of the divide, because some sites are really 
a hefty combination of clever (but still relatively simple) scripting, 
and development.

I think that my big concern is - there are probably a lot of Zope 2 
developers who do things in both modes.  I know that we're going to 
have to relearn a lot.  I get increasingly worried that the separation 
between "quick and dirty" (or just "quick and simple") scripting mode 
and development mode will be a vast chasm.  There are good reasons for 
keeping them separate, but what about the developer who also has to 
script?  Does he have to completely reconfigure his brain depending on 
which side of the chasm he's on?

Lastly, I just don't want to have (or to ever in my lifetime see) Page 
Template objects whose content is this:

<tal:script>
try:
	{i don't even know how to call things anymore}
except MyProcessingError, e:
	return container[page_we_came_from](request, errors=e.errors)
else:
	query = ZTUtils.make_query(message="Posted OK")
	return response.redirect('%s?%s' % (page_we_want_to_go_to,query))
</tal:script>

It seems ridiculous and redundant, like seeing PHP code that's all 
escaped in <?php ?> yet has no HTML whatsoever (or its HTML is 
foolishly is in print "<h1>..</h1>" statements).