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

[Jim Fulton]

Jeffrey P Shell wrote:
> On Sunday, September 7, 2003, at 07:46  AM, Jim Fulton wrote:
> 
...


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

That's hard to say. If it is, we will make it much clearer that
a transition is needed, because we're going to make it really
hard to transaition from one-off scripts to software in content
space.

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

Great.

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

No.

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

You'll be able to do this in either software or content space.


 > I don't want to go through complicated hoops as a developer
> to make end user pages. 

I don't think you have a basis for sayting that these are complicated.
I think there effort will be comparable to creating skin pages.


 > At the same time, I *don't* want quick and
> dirty.  In my experience, quick and dirty always leads to long and 
> painful. 

That's fine. You are a developer, not a scriptor.


...

> For the 'Developers who Script'

Developers can apply develer discipline when creating content-space templates
or scripts.


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

If the scriptor is working with developers, then maybe some of the developer's
discipline will rub off. Maybe they will use different techniques than the
scriptor would by themselves.

...

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

They don't.


 > Why do they need persistence?

They probably aren't aware of it.  But it makes thier life easier
and thus, makes the experience of using Zope more productive. They
can just "drop in" useful reusable objects that they wouldn't be
able to if they gave persistence.


 > Acquisition?

They don't.

 > Why do they need
> the higher memory overhead that Zope incurs over a system like PHP?

For what they are doing, there isn't higher memory overhead.  There
needn't be.  Zope 2 has a pretty low barrier to entry. I want to keep
that in Zope 3. I also want a cleaner transition from the simpler scripting
model to a developement model by more clearly defining and deliniating
the two models.


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

Sadly, probably true. But who knows for sure?

> Zope is not appropriate at all for simple systems. 

You'd be surprised how many people use it for simple systems though.
Many of these systems become less simple over time.

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

With Zope 3, Zope will be able to do less, when necessary. Thanks to
ZCML, I think it will be quite possible to create very lightweight
zope configurations that would be very suitable for sites like
these. I can imagine simple configurations of Zope that are run with
mod_python, or, possibly even CGI.


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


You're on!

 > Given that Zope is not particularly easy to set
> up (prior to Zope 2.7),

Oh come on.  If you use it's web server, it's extremely easy
to sat up.



 > install, configure with apache (virtual hosts),


Integration with apache is much harder. Many people don't do that.

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

There is "context" for developers.

...

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

You call things just like you did before, except that normal content objects
don't have a slew of ustility methods anymore.

> except MyProcessingError, e:
>     return container[page_we_came_from](request, errors=e.errors)

You can't use return statements from <script> tags.

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

Agreed. I'd hate to see this too.  Since people will be able to create
Python code outside of templates, I don't see why they would do something
like this.

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