-----Original Message----- From: Dylan Reinhardt [mailto:zope@dylanreinhardt.com] Sent: Sunday, September 21, 2003 10:31 PM To: William Yeung Cc: Zope Users Subject: Re: [Zope] Zope Development as a beginner On Sun, 2003-09-21 at 01:36, William Yeung wrote:

Dear all, Recently I am seeking new opportunity for developing low cost web based solution on linux (I was classified as MS Man :P)

Ah... welcome to the other side, then. :-)

in order to do lower end market. I was playing quite a bit different web development platform (ASP, ASP.NET + C#, and now Zope) and I found

the following conclusion: Zope seems has a good concept but difficult to manage in terms of granularity of the project.

I'll see if I can help out with that conclusion. * 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.

I found myself get very much feeling on Zope is actually still very script based- which is quite similar to what ASP and PHP did!

That's an understandable conclusion. DTML looks and smells like ASP and PHP but it is a big mistake to use it that way. DTML and TAL work better if you use them for as little as possible and hand off any real logic to Python. Developing this way delivers the best of both worlds: logic is done in a powerful, flexible programming language and layout is managed in a tag-based templating language.

I can see some of the different advantages (e.g. the acquisition of objects) on the web publishing side- but when I am thinking about implementing an high cohesion based system such way of maintaining objects and methods seems give me very much hassle on trying to coordinate things together.

Perhaps that's because the Zen of Acquisition has not settled in. Care to share an example of something that seems more cumbersome in Zope than in ASP or PHP? * 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 ... 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.

I think I am comparing this with ASP.NET, which seems give a very good way to separate UI and logic layer, while still has very good cohesion on each function of a webpage as a frontend to use. Think about I have 20+ different controls on a same screen which requires pretty much back and forth database activities and session control in order to finish a transaction... seems Zope is not very good at this kind of development.

It's hard to comment on that without knowing more. Maybe you could suggest a trivial example and give us a chance to take a whack at it? *I would really invite you to look at ASP.NET and C#, I think just an hour can give you very clear basics understanding. My feeling is that is much more cohesive.

However, even after the first sight I have to say I love python quite much- the language is convenient and clean, gives very good readability in terms of coding... so I really dream about if someone could come up with something more similar to ASP.NET instead of ZPT and DTML style

It may be heretical to suggest this on a Zope list, but you may be more interested in Webware: http://webware.sourceforge.net/ Webware uses Python Server Pages, an environment that is Python-focused but far more like ASP than Zope is. * I think what you are saying PSP is something similar to ASP, not ASP.NET... My friend has been talking about Apple WebObjects, while I am not sure if that is the one with similar terminology. * 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.

... also to allow a more easy to develop platform (I really dont like to keep going back and forth on the ZMI to build up my projects, I want to do all things offline and then test things at once) ... is there something out already, or my thoughts is just so different with you guys that no one think its a good way to do web development?

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... Zope can be thought of as a RAD tool. Building up apps through the ZMI *can* be a hassle, but if it's really *that* much of a pain, it's quite possible you're missing how much Zope is willing to do for you. Again, maybe a trivial example of *what* you're trying to do would give us enough material to show how Zope might improve on the process. * hey I can tell... At least no other linux based web platform provides such great session handling and error logging facilities... * I think afterall I might use Zope as well... Python itself is a good reason to implement... But I really hope someone would give more enhancements to the python web development... It has very good potential if being implemented in good terminology... Keep in touch :P William HTH, Dylan

I have tried boa constructor- I found that with a decent IDE things get much more smooth... I would like to know if there is any mature IDE that I could work with Zope for free or in a fairly cheap price then? William -----Original Message----- From: J Cameron Cooper [mailto:jccooper@jcameroncooper.com] Sent: Saturday, September 27, 2003 3:31 PM To: William Yeung; zope@zope.org Subject: Re: [Zope] Zope Development as a beginner

* 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