This sounds like a neat portal, I hope your project goes smoothly. My team just made beta today on version 2.0 of our product. Version 1 was written in PHP, and I have several comments on why you might prefer Python (and Zope) to PHP. Version 1.0 of our system was done in PHP for reasons similar to the "flat learning curve" comment you make below; it worked, and it was easy and quick to go from HTML to a working database application. However, when we wanted to expand our system or fix bugs in a core component, PHP fell short. This lead me to Python, and then to Zope. Python provides a programming language that "fits our brains". It's also one of the fastest, most productive languages I've ever used. When I'm unsure how a function works, or exactly how to slice a sequence to get the effect I want I can just start an interpreter and try it. Most importantly, it is far and away the most fun programming I've done in a long time. By adding Zope we get a great content management system, and a good framework for security and other nasty server programming problems. It also provides a basis for customization with DTML and properties. As for complexity, yes, Zope can be complicated. In particular, most of the problems I see are either super-deep-dark Python hacks that I really shouldn't have done, _or_ Python expressions being used inside DTML tags (this results in some syntax strangeness.) I didn't read the thread on checking the string for bad characters, but using a Python Script or a Python Product it would also just be a one liner. I don't know what is available for user management in Zope, because early on I decided my best solution was a user folder integrated in my product. However, I have dealt with several of the other issues you raise. For your special site versions, I think it would be easy to write a SiteAccess (a Product that comes with Zope 2.3.0+) rule that would first call a setup python script for each event (subdomain), and then let the normal site code run. This setup script could set various values that your main scripts could then refer to; things like default values for your input fields, special banners, a different style sheet, etc. I have not done this in particular, but I have done similar things. I would much rather try to do this in Zope than PHP. The plugin-applets you mention seem to be a combination of client-side components (like the date picker) and server side components (like message forums). Zope doesn't add much to client-side component development, but doesn't hinder it either. Server side component development and integration I've found to be much easier with Zope than PHP. For one thing, general shared configuration is easy in Zope (using properties), whereas with PHP you have to store all your configuration in source, or write some script to parse a config file. DTML includes built in support for the <dtml-tree> tag, which implements the expandable tree control you see in the manage UI. This tag calls back into your code to get the list of elements to show when a node is expanded, so it should be just as fast as your script code. It doesn't appear to allocate storage for anything it isn't using, so I think it will be quite fast. I've never used it with a data set this large, but I think it would work quite well. I don't know anything about doing WAP/WML with Zope, but once again since Zope has a nice consistent way to interact with content and configuration, I would prefer to work on multiple protocols (like WAP and HTTP) using Zope than PHP. With PHP you would be forced to invent your own internal layers; with Zope you could reuse existing mechanisms like ZSQL Methods and properties. As for database support and flexibility, my site was first built using MySQL, and I moved to PostgreSQL in a couple days, including building the new database schema (which was quite a bit more sophisticated, using foreign keys and checks that mysql doesn't support). Zope's internal database is also very helpful for storing configuration and static content (welcome pages, announcements, etc.) One problem I've seen people complain about on this list is the difficulty of updating a bunch of ZSQL Methods to use a new database adapter (if you switch from MySQL to PostgreSQL.) However, it's very easy to write a quick python app that connects to the ZODB and updates all your ZSQL Methods to use the new DBA. Dealing with SQL queries is much easier in Zope than PHP, but switching between database servers (if you've written a good layer in-between your application logic and the PHP DB apis) would be easier in PHP. I also do all my development in vi :). I just saw on this list earlier a file system for linux that mounts an FTP server into your file system. That would be great for Zope development. You can also use vim with the FTP extensions (my solution). -Randy
-----Original Message----- From: Jens Benecke [mailto:jens@jensbenecke.de] Sent: Thursday, March 15, 2001 11:02 AM To: Zope Users List Subject: [Zope] Zope "fitness"
Hello,
I've been lurking in this list for a couple weeks now and I've learnt a lot about Zope's capabilities. I've installed it and looked at a lot of guides, howtos and documentation on the Zope website. However, I'd like to make sure I make the right descision in choosing Zope and for that I'd like to ask a couple more questions.
We are running a "hitch-hiker" portal in Germany right now. It lets users insert a route they drive and others can search if they are going the same way, then drive together, saving time and travel costs. There are more services like contacting people, personalization, etc. in planning.
I like PHP because it was there to learn quickly and there was a flat learning curve if you already know HTML. Insert a small PHP tag here and there and so slowly extend your site, being productive all the time.
In the next couple weeks, I would like to redesign the site completely and -PERHAPS- choose Zope as the development environment. That at least partly depends on the answers I get here :-)
Zope, as I understood is a bit more than just a server based HTML scripting engine with database access. It takes OOP to the web and doesn't see pages, directories but objects that can be extended - which is an idea I like a lot. Some of the things that I am planning to do seem to be just the thing Zope was made for.
What I would like to know is not just whether things are "possible" with Zope, I want to know whether these things are _easy_ with Zope. I've seen the reply to the post where somebody was asking how to check if a string contained only certain chars and the answer was a 10-line <dtml-something ...> script, which kind of scared me. This would be a one-liner regexp in PHP or Perl ...
- Transparent User registration. When a new user visits our site I want to re-recognize him after that. With that info, I would like to know things like
- how much % of users came a second time - how much % of users viewed how many pages - etc.
- Non-transparent user registration :-) I need an "easy" (in terms of developing, and using) way for the users to save their settings and perhaps even choose several profiles for themselves, for address lists and so on.
- For certain dates, like festivals or special holidays, I want to take the whole site and "extend it" (see OOP) with a couple additional features, and present _that_ site in a sub-domain. Like
- different colours / title bar - pre-selected entry fields (e.g. for a sports festival when everybody is driving to the same place anyway) - etc.
- Plug in "applets". For example, for a date entry field I'd like a small calendar pop-up where people can select a date, and perhaps also select dates like "next monday three weeks from now" or something. Those might be available as PHP classes or as Zope products and the point would IMHO be how to integrate them in our system. Other extensions might be a message forum, email forms, rating other users, or whatever.
- One thing I specially like is the "tree" view method (which is also used in the tutorial). Is this a special Zope feature or just "one of many"? How would it cope with a _lot_ of data (I'm talking about x*10,000 entries in total)? (This might be a way of browsing available database entries like cities, for our users. ATM we are using more or less a flat list which is not optimal for 29,000 database entries.)
- Plug in WAP/WML and cell phone short message system capability. I want users to be able to query our system by sending a SMS (I've got a provider for this already) or using their cell phone as web browser via WAP.
- Database flexibility. The whole site will run on a MySQL or Postgres database (haven't decided yet) and I probably won't need Zope's internal Database. I guess this won't be a problem.
- vi compatability :) I haven't yet found out where the actual files reside, but one thing I do *not* want to use for regular development is the web frontend. File/Save, or :wa , and refresh the browser window is my idea of development environment ... I hope this is possible.
Those are the ideas I have. I've got a rough idea how to implement them in PHP and I can see it won't be an easy task whatever I chosse to use. I'm perfectly willing to lern Python and do most of the scripting in Python anyway (putting thousands of "dtml-tags" into the source isn't exactly the way to go I suppose) but I would really like to hear your input first.
Thanks a lot!!
-- Jens Benecke · " ...screams erupted at a Seattle hotel where Microsoft founder Bill Gates was addressing an education and technology conference. (...)" -- cnn.com, Reportage über das Erdbeben in Seattle