Slashdot Mirror

• Zope - good scalability;
• 4Suite - not clear;
• Apache mod_python - the best scalable thanks to Apache;

2. Separation of code from content : if you don't count DTML as "code", that may be true.

DTML is but one of several template schemes Zope offers. The technology is evolving fast, and even recent books are a little out of date on this one, but if DTML doesn't meet your needs then check some of the other alternatives. In particular, Zope Page Templates, with their HTML attribute based markup, are a very interesting approach that has the nice side effect of keeping everything within perfectly well formed HTML -- thus keeping the web monkeys with their whizz bang frontdreamy editors happy.

3. Authentication scheme

Again, you have a wide variety of options here -- basically anything you want, anything you could do in pure Apache, etc. A quick search for authentication & authorization on Zope.org turned up this nice paper on the component architecture of the security system.

In general most of your points deserve these kind of pat responses. It seems to me that the Zope system *is* very good, but the software itself is evolving much faster than the documentation is managing to keep up. That's not to say that the documentation doesn't exist -- it does, and help is out there if you want it -- but once the software hits a certain stable plateau a revamping of the documentation would be very welcome. Zope is an excellent system though. What finally won me over was to see a presentation on it at a Boston Perl Mongers meeting and having everyone watch in awe at the things this Python software could do so easily, with responses to the effect of "mod_perl is nice and all, but why haven't we come up with something high level like this?" Good question...

2. Separation of code from content : if you don't count DTML as "code", that may be true.

DTML is but one of several template schemes Zope offers. The technology is evolving fast, and even recent books are a little out of date on this one, but if DTML doesn't meet your needs then check some of the other alternatives. In particular, Zope Page Templates, with their HTML attribute based markup, are a very interesting approach that has the nice side effect of keeping everything within perfectly well formed HTML -- thus keeping the web monkeys with their whizz bang frontdreamy editors happy.

3. Authentication scheme

Again, you have a wide variety of options here -- basically anything you want, anything you could do in pure Apache, etc. A quick search for authentication & authorization on Zope.org turned up this nice paper on the component architecture of the security system.

In general most of your points deserve these kind of pat responses. It seems to me that the Zope system *is* very good, but the software itself is evolving much faster than the documentation is managing to keep up. That's not to say that the documentation doesn't exist -- it does, and help is out there if you want it -- but once the software hits a certain stable plateau a revamping of the documentation would be very welcome. Zope is an excellent system though. What finally won me over was to see a presentation on it at a Boston Perl Mongers meeting and having everyone watch in awe at the things this Python software could do so easily, with responses to the effect of "mod_perl is nice and all, but why haven't we come up with something high level like this?" Good question...

2. Separation of code from content : if you don't count DTML as "code", that may be true.

DTML is but one of several template schemes Zope offers. The technology is evolving fast, and even recent books are a little out of date on this one, but if DTML doesn't meet your needs then check some of the other alternatives. In particular, Zope Page Templates, with their HTML attribute based markup, are a very interesting approach that has the nice side effect of keeping everything within perfectly well formed HTML -- thus keeping the web monkeys with their whizz bang frontdreamy editors happy.

3. Authentication scheme

Again, you have a wide variety of options here -- basically anything you want, anything you could do in pure Apache, etc. A quick search for authentication & authorization on Zope.org turned up this nice paper on the component architecture of the security system.

In general most of your points deserve these kind of pat responses. It seems to me that the Zope system *is* very good, but the software itself is evolving much faster than the documentation is managing to keep up. That's not to say that the documentation doesn't exist -- it does, and help is out there if you want it -- but once the software hits a certain stable plateau a revamping of the documentation would be very welcome. Zope is an excellent system though. What finally won me over was to see a presentation on it at a Boston Perl Mongers meeting and having everyone watch in awe at the things this Python software could do so easily, with responses to the effect of "mod_perl is nice and all, but why haven't we come up with something high level like this?" Good question...

Zope may be what you are looking for. It's hard to beat for ease of use, maintenance, separation of code from content, etc. Zope is scalable, can also do enterprise-like stuff, connect to RDBMS and all, use any number of authentication schemes other than its own built-in scheme (LDAP, *nix passwd files, NT domains, databases). I believe you can also run Zope behind Apache w/SSL, which should take care of your security needs. Give it a try, anyway.

try Zope ... it's open source, and very well-known, too.

This mob make pretty good store-front software:
Bizar Software or you could do it yourself directly in ZOPE.

Please ignore the last paragraph of my last comment.

. o O ( Preview button...oh, yeah! )

You could probably build something on top of Zope (which comes with a ZWiki component), and might find gZigZag interesting.

Tinderbox, and Userland's products, though not open/free, are two other platforms to build on or learn from.

Usemod is another popular wiki, and there are dozens more WikiEngines, many of them licensed open/free.

There's also the book, The Wiki Way.

You could probably build something on top of Zope (which comes with a ZWiki component), and might find a href="http://www.gzigzag.org/

If you are going the Wiki route, I suggest you evaluate ZWiki. Zwiki is a Zope product that adds Wiki capabilities to Zope. this gives you the flexibility of a Wiki with the power of the Zope framework.

Zope might be a good start for you :

http://www.zope.org

Have you looked into Zope? It's well documented (the "Zope book" is freely available on the net), open source and has a great developer community to help you along in your first steps.

I'm not to familiar with the plone site or plone itself, but it's probably statement that plone is built *on top* of Zope and CMF, so you will need to refer to those two (and have a basic knowledge of them) to understand things like permissions, usermanagement, workflow and objecttypes in plone.

I'm not to familiar with the plone site or plone itself, but it's probably statement that plone is built *on top* of Zope and CMF, so you will need to refer to those two (and have a basic knowledge of them) to understand things like permissions, usermanagement, workflow and objecttypes in plone.

PHP is a widely used embedded-in-html scripting language, but it is by no means the first. PHP started off as a templating language, but features were continually added which it caused it to grow beyond Server Side Includes. As such, PHP is not a well designed scripting language. If you separate your code into functions, it is extremely difficult to track down errors, because you only get the line that the error occured on and not the line that called that function.

PHP is definitely very easy to start programming dynamic web pages, but it is
increasingly problematic as your code base grows. If you primarily do web
design and just want a little dynamic content, PHP's shortcomings won't affect
you. However, web based applications will run into problems with PHP
repeatedly. Besides the problem where it copies objects out of an array
when you use a "foreach", you are also stuck remembering to put an amperstand
in front of every object so it gets passed or assigned by reference and not
value.
For example:
$x = $obj; # $x is a copy of $obj
$x = &$obj; # $x and $obj refer to the same object

Besides the overhead of copying large objects, it just creates one more
"gotcha" that you have to remember to avoid. It is not that good code can't
be written, but it is so much easier to write problematic code.

Other projects for embedding scripting into HTML:
http://pmz.sourceforge.net/

http://webware.sourceforge.net/
http://www.kryogenix.org/code/castalian/

http://www.zope.org/

http://aspn.activestate.com/ASPN/Reference/Produ ct s/PerlEx/Embedded.html

Or Zope using CMF. Either of which are great solutions.

Is a real run-down comparison between the everything engine, j2ee, zope, and webobjects.

Yeah, so if you're just doing some random weblog, it makes sense to look at things at the unabstract, content-management-system level. But some of us find more interesting the idea of a system that allows for you to create a website by attaching abstract prebuilt website components together, defining the kinds of pages that you will have on your site as types, and then allowing the website to be created on a backend by less tech-saavy users who are shielded by the system from the raw code. This is what the above four systems basically are.. and it is much more powerful than just a simple CMS, though you can certainly incorporate CMS features into something you make with it.

(p.s. do I get mod'd up for posting the first real comment?)

Zope is an excellent web-based system, and there are many add-ons for extra features like calendars, discussion lists, etc.

Can run 'behind' apache, but it also includes it's own webserver.

I 'm using Tomcat for an old JSP-Application. It is rock solid. For new Web-Application-Development, the ZOPE-Framework is much easier to handle.

But name anyone who makes money running a huge website (Slashdot excluded, they don't make money) with MySQL

At Boston.com, MySQL and other open source technologies are used extensively, both for our live site and for back end infrastructure. I, for one, am not worried about the company going out of business any time soon. In addition, we run third party software, both open source & proprietary, that is able to effectively use MySQL as a storage mechanism (in addition to Oracle, which we'd rather not shell out that much money for thankyouverymuch). And in the future we'll be making use of Zope -- open source, Python based content management software -- for much or all public web content.

I mean, you're kinda right to point out that a lot of people like pointy clicky Windows-ness in their software, and that's fine. But there are other ways to go about this, and those other ways can be *much* cheaper and *much* more trustworthy, if not being beholden to vendor control of buggy source code is an issue to you (and it should be). Even paying support contracts to some of the organizations supporting open source software you can still come out way ahead in your business expenses, *and* you have more control over what the software is doing, which itself is priceless.

You aren't going to install a new database just to run a website when you already have one.

Well that depends, doesn't it? What if the security risk of exposing your corporate database is a higher cost than you'd rather bear? Wouldn't it make more sense to have a deployment tier of cheap, expendable LAMP [ Linux / Apache / Mysql/PostgreSQL / Perl/Python/PHP ] servers sitting between your safe little intranet and the big, scary world out there? What if your big expensive mainframe database systems were set up a decade or more before it occurred to anyone that this stuff ought to be globally accessible over thw web? Again, wouldn't it be easier & safer to put up a cheap proxy tier that is designed to work well over the web rather than screwing around with the old internal system?

Again, I don't want to seem like I'm just trying to shoot down your argument. Your concerns are valid -- open source is not a panacea. But at the same time, it can play a very effective role, either as part of the overall picture [putting LAMP machines in front of the big Oracle / mainframe] or, if you're brave enough, as the whole of the overall picture. Such a decision isn't necessarily corporate suicide. If you've got the expertise -- and hey, any interested college or high school kid can start playing around with the professional quality open source stuff for free if they want to, so the pool of experience developers is big & growing fast -- then licensing costs and often-dangerous code obscurity falls out of the picture. It's doubleplus good :)

This definition mentions such concepts as tables, relations between those columns, joins, etc. RDBMS is not an elitist term, as far as I can see -- it's a description of a class of databases. Other kinds of database exist: bdb (file-based hash), ZODB (an object store), hierarchical databases, and others. MySQL isn't one of those -- it is a relational database. It has tables, it has joins (even if integrity isn't ensured), it has a query language (that is not imperative)... it isn't a terribly featureful example, it does not pass the ACID test, but it is a relational database. A lot of the features given aren't even part of the original concept of an RDBMS (stored procedures in particular).

If MySQL is not relational, then what is it?

I don't know what the unix.com owners want to do with the domain (probably selling it for lots of $$ to AT&T?), but in trying to be 'not related to unix' they behave pretty lame, like stealing the webdesign from zope.org. Have a look

The only way to have a cross-platform help-desk tool, is to access it from a web interface. Discard all non web interface product - but these days all products do provide such web access.
Then you could use a free, opensource product. On the project I'm working on right now we use f2w Helpdesk. We had to install it on a linux Box. We had problems installing the prerequisite on our Solaris box. The software is quite simple to manage, and quite powerfull. Is 100% customisable and can even be accessed from Lynx based browser !!
The product is python and zope based.

Now we have a self-described high school webmaster wannabe who knows enough to adhere to standards while the so-called professionals are flipping through their MS certification study guides, so they can lookup which JavaScript hacks work with which versions of IE. Meanwhile, we're all chuckling about prosecution exhibit A.

Seriously, if you are really as described, check out the following:

• Python
• Zope
• PHP

Every once in a while I stumble across a little piece of evidence that suggests we're not all doomed to lifetime of watching the results of other people's bad code. I hope your approach to coding is matched by a healthy appreciation for Linux and all the other Open Source goodies.

application server: here and here

IDE: here, here, here

Oops, you really mean, written in Perl? Sorry, apparently all those tried, failed.

Haven't tried the latter, but it may fit the bill. DocumentLibrary home

"In my opinion, an open-source ColdFusion would be a hell of a lot more interesting than an open source Flash."

Zope is a free (as in speech) application server written in python.

From the Zope website:

Zope is a leading open source application server, specializing in content management, portals, and custom applications. Zope enables teams to collaborate in the creation and management of dynamic web-based business applications such as intranets and portals.

As far as programmers are concerned, I'd have them take a good look at MaxM's Easy Product writeups.

I kid you not, the above product is nigh-indispensable to programmers who need to make custom Zope objects, but have trouble with some of the overhead of rolling products entirely from scratch. GO READ IT IF YOU'VE HAD TROUBLE OF THIS SORT.

Anecdotally, witness the difference between these threads on the Zope list, both from the same user: Before, After

As far as programmers are concerned, I'd have them take a good look at MaxM's Easy Product writeups.

I kid you not, the above product is nigh-indispensable to programmers who need to make custom Zope objects, but have trouble with some of the overhead of rolling products entirely from scratch. GO READ IT IF YOU'VE HAD TROUBLE OF THIS SORT.

Anecdotally, witness the difference between these threads on the Zope list, both from the same user: Before, After

As far as programmers are concerned, I'd have them take a good look at MaxM's Easy Product writeups.

I kid you not, the above product is nigh-indispensable to programmers who need to make custom Zope objects, but have trouble with some of the overhead of rolling products entirely from scratch. GO READ IT IF YOU'VE HAD TROUBLE OF THIS SORT.

Anecdotally, witness the difference between these threads on the Zope list, both from the same user: Before, After

I've found the mailing list and #Zope on the Openprojects.net irc servers invaluable for solving problems with Zope. Remember the Zope Corporation and other have used Zope for high profile projects such as CBS New York.

As far as the article topic, Zope has the CMF project which might give a good headstart on what they are after.

Aha, I see other threads are pimping Zope and the CMF so I'll leave it at this...

I've found the mailing list and #Zope on the Openprojects.net irc servers invaluable for solving problems with Zope. Remember the Zope Corporation and other have used Zope for high profile projects such as CBS New York.

As far as the article topic, Zope has the CMF project which might give a good headstart on what they are after.

Aha, I see other threads are pimping Zope and the CMF so I'll leave it at this...

I second that.
Plus, I would think about getting paid zope consulting to get you of from the ground and continue yourself later on.
Let someone build the hard parts (business logic etc.) and do the easy parts yourself (presentation logic).

Whatever sales droids of proprietary content management system may tell you, they don't work out of the box - at least not more than zope does.
You'll always find things which don't work the way you want them to, making custumization needed, like adaption to your business' processes or whatever.
In reality, many of the important CM makers make most of their money by consulting etc.
Take a look at zopes content management framework which is an add-on more tailored to typical content management use cases - oh, and ignore the ugly side, something new is in the works.

It all comes down to:
$total_cost = $cost_of_license + $cost_of_consulting + $cost_of_own_time

With zope, $cost_of_license == 0 at least, and I guarantee that zope gives a very good start to get the others quite low.

I know, I know. "Nobody knows python". Zope is fairly mature, so you can run it and do a lot without getting under the hood and mucking with the source.

Also, Zope allows you to write scripts in Perl or Python, so you can implement site logic you need in a language you already know. You can also use it to connect to existing databases.

Plus, it wouldn't hurt to learn a little python.

Zope will take out a lot of the busy work of rolling your own and you can concentrate on customizing it.

The Zope Book is on-line and the software is free, so the initial investment is just you time twiddling with it to see if it meets your needs. I looked at it this spring, but it was overkill for the project I was working on.

I know, I know. "Nobody knows python". Zope is fairly mature, so you can run it and do a lot without getting under the hood and mucking with the source.

Also, Zope allows you to write scripts in Perl or Python, so you can implement site logic you need in a language you already know. You can also use it to connect to existing databases.

Plus, it wouldn't hurt to learn a little python.

Zope will take out a lot of the busy work of rolling your own and you can concentrate on customizing it.

The Zope Book is on-line and the software is free, so the initial investment is just you time twiddling with it to see if it meets your needs. I looked at it this spring, but it was overkill for the project I was working on.

To go all out in the Zope world I'd suggest a CMF Portal, potentially one based on Plone

Could you be more specific about what is "web stuff"?

Sure. Web stuff is using a web server to serve a GUI to a client or to act as an RPC end-point (e.g., XMLRPC over HTTP, SOAP over HTTP, or roll-yer-own over HTTP).

Zope excels at the GUI by truly separating presentation from logic. Check out Zope Page Templates, which use an attribute markup language to embed presentation control in XHTML tags. Simply mind-blowing. Also, Zope is the only web server I've run across (I'm sure there are others...) that realizes the promise of reuse thru Object-Orientation. The quintessential example is style sheets. Under IIS/CFM/J2Whatever, you typically have to include a style sheet in every document that should use it. Under Zope, you instantiate it once, include it once, and sub objects inherit it automatically. Even better, that behavior can be overridden by careful instantiation of other objects in the hierarchy.

As to the RPC, again Zope is stellar. It does XMLRPC out of the box, and I hear SOAP support is coming soon (I seem to recall a package that makes this possible today, but I'm too lazy to surf over there and find the link for you). I mentioned a Zope app I recently deployed earlier in this thread, and with that app, we act as both RPC client and server. Using Zope/Python made the RPC stuff almost trivial, and our Marketing people were simply floored by how much we implemented in so little time.

Does that answer your question? Please let me know if I can answer anything further about Python or Zope. I've been programming almost 15 years, and I know 13 languages last count. Python is the only one about which I've ever felt passion.

You can get Zope here.

At IPC10, they were handing out ZOPE on a Rope. see this picture

If workflow is your interest, you should check out Zope's Content Management Framework - and in particular the Plone implementation based on this. Plone makes the whole thing more user friendly (basically, the CMF sucks in its standard version ;) and also incorporates DCWorkflow as part of the solution.

Disclaimer: I'm one of the people behind Plone, so I might be biased ;)

It's released under the OPL and both an HTML version and a PDF version of the book are freely available.

It's released under the OPL and both an HTML version and a PDF version of the book are freely available.

It's released under the OPL and both an HTML version and a PDF version of the book are freely available.

It seems that "old media" (ie: books publishers) is recognizing this fact a lot faster than newer media (ie: movie and music publishers). I recently finished my first book for New Riders (see www.brendonwilson.com/projects/jxta), and they not only allowed me to post the draft chapters when I asked, but even suggested posting the final version!

This has apparently been accepted by New Riders lately for a few books. My acquisition editor, Stephanie Wall, has done this for about a dozen books, including the Zope book. According to her, New Riders has also come to the same conclusion: offering free online versions of books doesn't hurt the publisher's physical book sales. After all, if someone is crazy enough to read the entire thing off a monitor or print it off, it's doubtful they would have bought the book anyway.

O'Reilly has also taken to doing something similar with its Open Books Project.

Of course, the question is how long this phenomenon will last once we have display technology that allows us to take these electronic books with us in a form indistinguishable from a normal paper book...

Those who think that web services will only run on IIS are having the wool pulled over their eyes by Microsoft. For an open source implementation of the SOAP protocol, try Zope. For a real world example of use of web services, try Google's Web Service-based API. One could argue that the net has more to gain from the advancement of web services than Microsoft.

-Peter

That's pretty much the case for most general purpose CMS (rather than something site-type specific like Slashcode, PHPWebsite or whatever). Whether you're talking about Zope or Vignette, you're still essentially getting a high-level toolkit, with some nice APIs to handle stuff at the level of user authentication, workflow capability and so on.

You're still going to have to put something on top to run your site, whether it's a higher-level still toolkit like CMF (Content Management Framework, note) for Zope, or Multisite Content Manager (previously known as Enterprise Application Portal) for Vignette.

• Everything is an object
  
• Dublin core metadata
  
• extremely granular security
  
• 100% customizable w/Python/Perl/C
  
• XML
  
• XML-RPC
  
• lots of great open source products (essentially plug-ins to the app server).
  

• Everything is an object
  
• Dublin core metadata
  
• extremely granular security
  
• 100% customizable w/Python/Perl/C
  
• XML
  
• XML-RPC
  
• lots of great open source products (essentially plug-ins to the app server).
  

See Zope fishbowl. It's a nice summary of a very lightweight process with some well-written thoughts on why such/any process is necessary.

As far as where to start, start with what you have. Most (not all) developers are happy to put their meeting notes, design docs, and such in a common/standard location and format (I recommend a text-based format in a revision control system) if one is simply designated. Someone whose technical ability they respect may have to remind some of the developers from time to time to put their docs in the designated place or to create a document from some important conversation.

Be careful not to attempt to switch from what you have now (nothing) to something unrealistic (full UML class and system diagrams, workflows, and state transition diagrams for every project). Be realistic and simply start to collect what you've got. Designate a spot for hard copy documentation and electronic documentation. Another easy first step is to designate a common format (ASCII, HTML, PDF, StarOffice, whatever).

Give that a few months to sink in. Then start to list common documents that should normally be associated with a project. Several separate "artifacts" of a project may include requirements, functional (user-visible functionality) design, detailed (class hierarchy and component interaction) design, implementation notes, decision log (bullet items of decisions made with date and those involved).

Remember: something is better than nothing. If each project simply has a decision log (Greg and Sheila decided not to support wizbang with a froznobit because it would cause all the tulips to wilt), then you have a start. Six months later, when someone asks, "Why didn't we use froznobits to implement wizbang? Maybe we should fix that," they'll have somewhere to look for the answer. The same can be said of requirements and functional design. Developers can usually figure out detailed design by long hours spent pouring over code. There's no way to divine what a program is *supposed* to do if there are no comments and no requirements and no functional design.