[Zope] Zope Development as a beginner

[J Cameron Cooper]

>
>
>* I think I would put this as an example- the example shopping cart.
>Each function become its own python script, while they are all in fact
>doing the same goal- should actually have these all things warp together
>in a class say, a ShoppingCart, and then put tiny scripts to invoke
>those methods. To use n files to just join together and become a class
>(with the folder context) is really... Looks really messy, which doesn't
>give me a good sight of looking the entire business logic together.
>  
>
That's beause it's an example of how one might construct TTW 
applications. These are one-off types of things. But it's not the only 
way to do it.

You describe almost exactly, but without actually naming it, Python 
product development for Zope, where you define a class that becomes 
Zope-publishable.

When Zope 3 comes around, things will be even better, as you will be 
able to basically write a Python class and plug it straight it (and 
probably even TTW.)

>* I can understand- I am not saying that its more cumbersome than ASP
>(which is rubbish anyway, even I am on MS platform I hate it) or PHP,
>what I mean is ...
>
As an aside, I couldn't agree more. My first exposure to web application 
programming was ASP. It's a wonder I even thought of continuing.

>Like the paragraph I have stated above, about how
>these all-together business logics being broken into so many pieces in
>order to get it work together as a single goal.
>  
>
The Zope TTW way of building things sort of straddles the line between 
application and web site. (It's almost the very definition of a dynamic 
web site.) There are more structured ways of doing things, as elsewhere 
explained. At that end of the spectrum the ZMI becomes more of a tool 
for managing the data of your site than as a development environment, 
which is the way I suspect you see it.

>* ok a quick example, declare 5 textboxes and 2 buttons on the ASPX file
>(similar to a template, except it declares object context) and then at
>the class file behind the scene (aspx.cs file) all these objects are
>directly being related back to actual object variables (member variables
>in the inherited page class) and then you can either use event handler
>to handle the click event of that button, or use properties to refer to
>a particular textbox's value, and change it on the class file, all these
>dynamic happened changes will be feed back to the web browser client
>after the post event has finished. You don't even have to care when to
>use form post- ASP.NET generates all necessary client script and such
>event will get posted to web server at the right time (e.g. when the
>button is clicked), so each form is a class, each control is member of
>the class... Very straight forward, I think most GUI based OO program
>obeys the same syntax approach as well.
>
I'm not sure I quite understand the scenario (a bit of domain mismatch, 
I think), but I'll give it a go.

Most Zope programming takes a little lower level approach, at least the 
way I do it. A form is submitted to a handler script, which then does 
something with the data. (It can be pulled out of the REQUEST or made to 
look like the parameters of a method call.) An action can be performed, 
or the properties of an object updated.

There are techniques that are more like what you describe: Archetypes 
and Zope 3 schemas allow you to create a schema which will generate 
forms for you, validate input, and presumably handle posts that update 
the data or pass it to some function that does something with it. (I'm 
probably not explaining it too well, since I don't do this yet.)

>You might be interested in Python Products.  This is how you add new
>objects to Zope, but if you want to you can create whole applications
>this way.  The development cycle for these is (can be) much more
>offline, though you'll obviously need to test them in a Zope install to
>validate the UI.
>
>*Agree- in fact I am looking at Zclass as well... Think that might be a
>way to go as well... However that one sounds quite complicate to the
>other end...
>
I always advise staying away from ZClasses: they're too much magic and 
often trouble. Subtle and quick to anger, as they say. And if you 
dislike the TTW model, you definitely won't want ZClasses. Python 
Products, on the other hand, are v. nice. (Or, at least, much nicer.) 
There are certain idiosyncracies, of course, but it's not too hard, really.

And a note on separation of logic, data, and presentation: the newer 
Zope technologies like Zope Page Templates (best template language 
ever!) encourage but do not enforce this separation. You're given plenty 
of rope to play with, but you must be careful of making the noose. In 
general, ZPT are for formatting only, Python scripts are for glue, and 
Products are for data and behaviour of that data.

                --jcc