Dylan Jay writes: > Ricardo Alves wrote: >> Dylan Jay wrote: >> On the other side, we must ensure backward compatibility with the >> old-style code in a sensible way (IMHO, a software project can't be >> more disrespectful with its users then when it breaks compatibility >> with older versions). > > Well I guess herein lies the problem. Its a three ways tussle between > innovation vs backwards compatiblity vs reduced complexity. It seems > try to solve one and the others suffer. But does it really have to be > that way? > Some questions that come to mind are:- > Are we kidding ourselves with backwards compatibility? There aren't > many addon products, skins or other customizations that don't have to > be upgraded to work with plone3. All my sites need to be modified. And > if they are modified even a little, in some sense I'd rather spend the > time rewriting to work with the new technology... if it was not going > to be obsolete in the near future.
I think you have a good point here. Backwards compatibility is only one part of the story. The other is that Plone's codebase is maintained by individuals, often in their unpaid time. And adding new technology and features is by far more sexy than rewriting older parts to conform to recent best practices. It's more rewarding for developers who get the praise for adding new functionality, and it's better for marketing folks, because they can advertise another feature. At the same time, like you observe, it's quite bad as far as the learning curve for newbies is concerned. There's an argument that one can ignore the old technology when developing for Plone nowadays. But that's only true until you have to modify or otherwise work closely with existing functionality, and until you have to debug legacy code. I don't know a solution for this problem except that we could try and achieve broad consent that rejuvenating existing Plone code is just as essential, and that backwards compatibility can hurt. > Take for instance portlets. I had to do my first plone3 style portlet > the other day. It seems that formlib is the prefered way of doing > forms with portlets so I took the hit and learnt formlib. But how long > is formlib going to be around for? Will learning formlib help we with > coding other parts of plone? Now there is z3c.form. Will I need to > learn that by plone 3.5? As a side note, z3c.form is fortunately consistent with lots of APIs that developers already know when they're coming from formlib. It's very similar to formlib and it builds on the foundations such as zope.interface and zope.schema. z3c.form is much closer to formlib than CMFFormController or Archetypes. -- Daniel Nouri http://danielnouri.org _______________________________________________ Product-Developers mailing list [email protected] http://lists.plone.org/mailman/listinfo/product-developers
