There seems to be some rumblings on the Plone front for us currently. For our main stable of development however, we have moved away although not totally from Plone to django. The main reason here is that for Plone deals to be feasible for us, we either have to:
1. Lock requirements down really tight so that the juniors can have a go at it .... or
2. Sic some seniors at it.
In my own experience, it seems that while Plone can be easy if worked within a tight parameter, try swaying a bit out of those parameters, when you have to peer under the hood and you are in a world of pain. It's hard to gain leverage using Plone this way. django on the hand has been actually quite young developer friendly for us and they end up being actually more productive compared to when they are forced to make some funky changes in Plone. Most of the business applications that we build require a light framework and is normally built from ground up. This means that Plone is sometimes an overkill for these apps which is a shame because Plone almost always appear like a good fit in the beginning. In the end, to be able to shoehorn Plone in means a lot stripping functionality and code out.
For what it's worth we still try to train up our guys to do basic Plone stuff but only time will tell if it makes business sense to invest any time in Plone/Zope.
Wednesday, September 24, 2008
Subscribe to:
Post Comments (Atom)
1 comment:
Plone is a CMS, and as soon as you try to do anything else, it gets complicated. My recommendation is that if you try to do that, generally ignore the Plone part of Plone. Instead of forcing Plones content types into doing non-ploneish things, go directly on Zope2 or Zope3 technologies. These can be used within Plone, but you don't have to have archetypes or DCWorkflow on every little thing. ;)
This may or may not apply in this case...
Post a Comment