As usual, not having all the history behind me, I am asking questions that many people would already have thought through…Very happy to have my ideas systematicallyterminated.
I’m involved with a group writing an information management system – kind of CMS related. I’ve been mulling over the choice of technology. I’ve been deeply involved in programming J2EE for the past seven years and now am learning to create web apps with Plone and Zope. While I think the “Plope” combination is very powerful I do have some concerns. Here’s my thought dump…
Long term viability: I’m still worried about the nature of Plone as our implementation base. Hearing comments around the office over the past couple of weeks it seems that many of the issues that people struggle with are related to grappling with are to do with
“getting Plone to do what we want”. I wonder if we’d be better off focussing on pure Python and only using Plone / Zope where we absolutely need to. For example, while the workflow built in to Plone is enticing, our workflows are not actually very complicated. As I see it we basically need to be able to creat an object, populated it with data from a web form and then store it, at the same time, notifying a particular user of an event. The user responds, and so on. This could be done quite easily with pure Python objects and, say, an email library. The only thing we then really need Plone for is the http runtime and the ZDB. (And these can be provided by other systems such as Django or Turbogears with MySQL)
If we continue with this technology, would the system needs to be in a state that can be easily handed over to another party for continued maintenance / development if the current team disbanded?
Another issue is the ZDB. While they may be efficient, the IT world has not embraced object databases. Oracle, DB2 and MySQL dominate for good reason. The management of the data is centred onone piece of software. The data can be manipulated, optimised, (and fixed) and viewed independently of the application layer. Data reporting systems can be used without needing to build onto Zope/Plone and without exporting and manipulating XMLised objects.
In my previous job the developers were very keen on Python and Ruby but our clients would be extremely unlikely to accept systems based on those technologies even though they might have many benefits. The key is ownership and maintainability. The same goes for the current system. For how long can we guarantee the availability of Plonedevelopers.
Large, less flexibleorganisations seem to prefer tried and accepted technologies and, in my experience, rarely go with open-source, preferring to pay big dollars for supported software. They would likely prefer more broadly accepted standards such as J2EE which is implemented by a raft of vendors and open source groups, rather than being locked into Plone.
At the very least, our system should be written with portability in mind. If we decide to drop Plone and go with straight Zope or Django or TurboGears then we would be in a better position if as much of our codebase as possible is devoid of Plone dependencies. Part of our system architecture design should work towards encapsulating as much of the system as a simple Python library which is then called by the Plone dependent part.