[Product-Developers] [ANN] New simplified product skeleton for Plone
mikko+plone at redinnovation.com
Wed Mar 21 09:05:09 UTC 2012
>> * sane_plone_addon_template, plone-customizations etc. efforts will be
>> merged in one codebase which is documented in collective-docs. This add-on
>> could be available also in unified installer, in not installed state.
>> collective-docs example code could rely that you have this add-on present,
>> it's views.py layout is fixed and so on.
> The one problem is that there are many equally valid variations on what
> people want, and trying to produce on skeleton with 'all' examples makes
> the skeleton complex. You chose the five.grok route, for instance; you also
> chose to include CMF skin layers. I haven't registered a portal_skins layer
> for *years*, preferring z3c.jbot and views.
z3c.jbot is preferred template customization approach, as per documented in
the instructions. However touching portal_skins is still required for some
.py and .cpy actions, e.g. overriding login destinations. If you have not
touched portal_skins layers for years you have been quite lucky :) But this
is an implementation detail which can be made an optional feature people
can later enable as you are right and luckily the number of use cases where
you need to touch portal_skins is shrinking.
> The other thing plone-devstart chose to do, which I think makes sense for
> 'new' users, is to not worry about egg namespaces or custom naming at all.
> Every user of plone-devstart could have an egg called
> 'plone-customizations', and it'll have the same name if the use
> plone-devstart on ten projects. They will never release that egg. They'll
> deploy it, from a tag or trunk, straight out of source control.
Also this holds true for youraddon which is an egg itself and currently
available in any buildout by simply git clone + buildout.cfg update. To
make the development path to "professional egg" easier there exist a Python
script called personalize.py which can later rename the egg if needed.
personalize.py script will also clean up stock examples and ponies from the
> * Let's deprecate Paster + ZopeSkel, or any other related templating
> solution, as I believe I can achieve the same or better results with a
> bunch of files, string replacement and 250 lines of barebone Python script.
> They only make things unnecessary complex and not maintainable.
>I think we need to thread carefully here. I agree that simple is better.
But ZopeSkel has served us >well. I think there will be a need to
instantiate different things. We won't come up with one skeleton to serve
all needs, so having some way to manage deployment of skeletons and
consistency is useful.
ZopeSkel has served us well, but does not serve us well currently.
Templates are outdated. No one is maintaining them. Code base is mess and
not accessible by external developers. The development is stagnated. The
future is open. It's time to retire ZopeSkel. RIP ZopeSkel.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Product-Developers