O'Reilly Interview with the Plone Founders 124
Alexander Limi writes "Just in time for some light weekend reading, O'Reilly's OSDir.com has published a byte-sized interview with the two founders of Plone. This is a nice follow-up to the earlier discussion on Slashdot, and covers a lot of the unanswered questions people directed to us earlier as the surprise winners of the O'Reilly COMDEX competition."
Re:A bit telling (Score:5, Interesting)
Zope is just confounding. Plone makes it easier to get some things done. But sooner or later you are going to have to create a template or a script and then you'll be scratching your head and saying "wtf".
When I was first using plone it would take me hours to find where some text on the screen was being produced or where to go to change it. I am still perplexed about where the actions for the user bar are for example. And of course sooner or later everybody will get a visit from the "spammish aquisition".
I am waiting to see what zope3 and plone 2 are going to be like. I hope they make it easier for mere mortals to use them.
Re:What's Plone? (Score:5, Interesting)
Does anybody else find it slightly amusing that Plone is running on Sun's network - on Sun hardware no less - and no Java in sight? ;)
Zope - a dream come true. (Score:5, Interesting)
If you don't have a knack at OOP *and* aren't willing to read through some messy, redundant and unfinished third party code experiments you're gonna have some hard time getting going with it.
Beyond that Zope is nothing less than the ultimate refrence for the way all server side stuff will be done in the future. Zope comes with a fully integrated object relational Database, runs with and on, what I call the fully GPLd equivalent to Java, Python and is an absolute breeze to develop with.
Technology wise Zope makes BEA,
The problem with Zope (and Plone) (Score:3, Interesting)
First, Zope's internals are overly complex and sometime guided by ideological choices (the object database IMHO). It's a closed world with its own culture and logic. Its culture doesn't promote interoperability (again that's my feeling). It takes you out of the Web and into Zope Universe (after all this year, there are still problem when you want Apache and Zope to talk together, eg. Digest authentication).
Zope is often dubbed (I think Jon Uddel first said this) "Python's killer app" but I find it very non-Pythonic: overly complex, non-explicit and un-welcoming. Plone adds another layer on top of CMF, Zope, the object database... it is very difficult to understand.
I think that the best web setup is still a light and fast frontend (and PHP is good at that), a solid Database (PostgreSQL is better than a lot of people believe) and a third "business logic" tier which can be a separate application or shared between the frontend and stored procedure in the database. It's not the perfect theorical model but it's manageable, it stays simple (if you work hard enough to keep it simple) and you can evolve a simple website towards this model without restarting from scratch each time the requirements change ("embrace change", remember?).
I'm fascinated by Zope and Plone because they do so much and frankly, I don't know if I'd be able to write such a piece of software. But I think it goes in the wrong direction: the application server direction. It tries to coerce the light, simple and stateless nature of the Web into the heavyweight transactional world of corporate applications, just like the Java world does (Java Server Faces seems to make it worse). It is difficult to make a good Web application, but it's even more difficult when you fight against the Web and the way it works.
Re:What exactly *is* Plone? (Score:1, Interesting)
Well, we are trained in this world to accept only the rational and the logical. For a while, we were all able to escape that together. As children, we do not separate the possible from the impossible which is why the younger a mind is the easier it is to free, and why they were able to create Plone out of nothing but five letters and some hype. But now the rules have reasserted themselves. And it is harder than ever to really know what Plone is.
No one can tell you what Plone is. You have to see it for yourself. Plone is all around us. And if you can figure out just how to give programs to people on Minidiscs, and you don't understand Plone, then maybe you are The One.
It's dangerously unstable (Score:2, Interesting)
It would make far more sense, to me, to store things in separate files. That 'all your eggs in one basket' thing, you know.
Re:A bit telling (Score:4, Interesting)
While Zope documentation can be kindly described as minimalist, Plone documentation simply doesn't exist and what little there is is 100% wrong. Hell, I've had some of the plone developers send me solutions to problems and their solutions don't work (usually because they've skipped 2-3 major steps in their directions, assuming that I know as much about their undocumented product as they do).
I think Plone is a great project, and it will likely become an integral part of Zope, if you want to do anything other than slap a different skin on it you are SOL. I'm particularly bothered by the fact that they override many of the default behaviors of Zope/CMF and there is NO way around it so it is not possible to port a Zope/CMF product to Plone without completely rewriting from scratch.
Re:The problem with Zope (and Plone) (Score:3, Interesting)
It took me a while to set up Zope/Plone. There's a nasty bug in Debian's distribution of Plone, but thankfully there's a super easy workaround in the BTS [debian.org]. It also took a couple visits to #plone@irc.gnu.org to set up an actual Plone instance, but in retrospect it wasn't that hard. I got the Apache passthrough working too. Now, Plone's setup phase is done. Anything I need to change is done via GUI, and the Structured Text system is perfect for marking up content without obfuscating it. Oh yeah, and the Structured Text was the only thing I actually had to look at the Plone docs for. It's probably even easier when you use them start to finish.
I've used e107 [e107.org], PostNuke [postnuke.com], XOOPS [xoops.org], Slash [slashcode.com], Scoop [kuro5hin.org] and probably a few others. They're all neat, but I've had way more problems with them all, from just plain failure to strange errors to lack of features. e107 does have a TON more themes available, though.
You say Zope is going in the wrong direction, but I fail to see how. With Zope, you can build webapps into your Plone site - just don't ask me how. With most PHP-based CMS's you still have to install an SQL server of some flavor, and I doubt if you can build webapps in. You complain about Zope/CMF/Plone being three-tiered, but really CMF is just an addon to Zope - it doesn't add complication. And I think it's pretty sweet to be able to manage all your Zope stuff through one interface - including all your Plone sites and whatever else you've got going. You also complain that Zope is a "closed world" because of the object database. Yeah, it's about as "closed" as any other website that has an FTP backend - i.e. NOT.
And as far as speed, I haven't noticed a bit of difference between Plone and e107 (the only other CMS I've ended up using for real). I'm not pretending I get any real traffic, though. But to balance that, I've got a horrible setup - at the moment a P4-1.4 with 256/RAM and a cable modem with an upload cap of 256Kb.
In short, Plone rules. Not sure how it does it, but it does.
Re:Plone 2, Archetypes (Score:1, Interesting)
Database Connectivity (Score:3, Interesting)