Ricardo Alves wrote:
Dylan Jay wrote:
Gilles Lenfant wrote:
And the learning curve of Python + Zope2/3 + Plone is about 6 months
for a good newbie. And Plone 3 added about 1 month to that learning
curve - compared with Plone 2.
I think that one of the goals for Plone 4 (5?) should be to cut this
learning curve to 4 months, this should really attract more people to
Plone.
Yep. It would be great when skins and form controllers and python
scripts never have to be learnt or considered.
So, what would be considered? XML and ZCML? Are we still talking about
how to "win the battle for developers"? Developers tend to like to code :)
I'd prefer zcml z3 browser views IF it was the only thing I had to learn
to customise plone.
We have a big application stack. Making easier to extend Plone without
the need to learn the the whole underlying technology is good, but only
as a starting point. Developers eventually need to understand the magic
behind-the-scenes. And the more we hide it, the more magic and hard it
will look like.
Exactly. Hiding technology with simpler but less flexible technology
isn't the answer. Perhaps the answer is reducing the size of the stack?
So the number of concepts needed to understand the full stack is less.
Plones high learning curve is caused by too much choice of ways to do
things IMO. We need 1 or 2 ways of doing things at most. and if there
is more than one way they need to have a very clear reason why and
when you use one or the othe?
This is true. For example, CMF skin layers vs browser resources, views
and layers is causing lots of confusion for newbies.
But that's caused by one of the characteristics I love most about the
Zope/Plone world: the unstoppable technology improvements that make the
code base bleeding-edge all the time. If we hadn't made the move for z3
style code, for example, we would still be only using old z2 style
products, with no benefits from the z3 component architecture, and plone
would probably be dying, while some other projects would be rising on
top of zope3...
I do agree to innovation is a great thing and that moving to z3 is a
great initiative but...
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.
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?
This is an incredibly difficult problem to solve I know. and perhaps
thats why its easy to dismiss and put it in the too hard basket. We have
many different people working on plone. The really productive ones
already know all the technology in the stack, when they know there is
create new technology they can bring in to solve a problem (like
z3c.form) then who is going to stop them?
Don't get me wrong. I agree we need to make Plone more attractive for
new developers. We just should be aware that some of the aspects that
make Plone difficult/complex are motivated by some of the principles
that drive the community and its development approach.
but what I wanted to raise awarness of is that I think too much
innovation can kill plone as much as too little.
We could be driving forward but leaving everyone else behind. The more
technology we introduce without replacing and COMPLETELY discarding old
ones, the harder we make it for developers to join and help us and
eventually we run out.
Is it a goal to get rid of old ways of doing things like form controller?
I think an excellent goal would be to make martins book half the size it
is today. I suspect if another version were released to today it would
have to include more chapters rather than less :(
_______________________________________________
Product-Developers mailing list
[email protected]
http://lists.plone.org/mailman/listinfo/product-developers