* 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