[Product-Developers] [ANN] New simplified product skeleton for Plone
optilude+lists at gmail.com
Wed Mar 21 08:12:54 UTC 2012
On 21 March 2012 04:50, Mikko Ohtamaa <mikko at opensourcehacker.com> wrote:
> Hi Martin & co.
> On Tue, Mar 20, 2012 at 20:35, Martin Aspeli <optilude+lists at gmail.com>wrote:
>> On 20 March 2012 17:15, Mikko Ohtamaa <mikko+plone at redinnovation.com>wrote:
>>> I have created a new Plone add-on code skeleton based on Plone 4.1,
>>> It is not based on any template engine: just clone and go. Tries to be
>>> minimal as possible. Instructions provided.
>> Cool ;-)
>> Did you have a look at the 'plone-customizations' egg provided by
>> plone-devstart? Wondering if it serves a somewhat similar purpose.
> I checked out plone-customizations egg and some other stuff which was
> pointed out for me on this mailing list and elsewhere.
> I was just wondering if the following goals where possible to achieve the
> minimum barrier of entry for new Plone developers
> * plone_devstart serves as a development start-up buildout, but eventually
> these changed should be merged to unified installer so that no separate
> "installer" for developers are needed. Even in the worst case we should ask
> people to run "cp development.cfg buildout.cfg" or similar. I don't see we
> have other barries besides by simply making the default buildout runnable
> without virtualenv (buildout is broken...). We know what must be done to
> accomplish this.
We had that debate in the other thread, but there are other environment
issues that trip people up (e.g. wrong Python, missing libraries) that we
need to check too. Maybe buildout could check those (from an extension) of
> * 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.
> * there is only one Plone add-on code skeleton, unlike separate Zopeskel
> templates. This code skeleton will have "features" you can enable, like
> content types. E.g. the default sane_plone_addon_template comes without
> base file content.py, but you could throw it in a folder after which you
> can macro create more content types using a simple Python command which
> copies in files and renames them if needed. Currently it is great mess
> because you need to create one product for content types, one for themes,
> so on.
I think for 'mature' use cases, it makes sense to separate into packages,
but I agree that it's better to have them co-located for simple use cases.
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.
That's not how professional Plone development shops choose to work, because
they have more complex demands. But it's perfectly good enough for most
people, and it's not that hard to learn how to manage source code more
effectively once you've learned how to write the source code in the first
> * In the optimal situation no code generators should be used with Python
> and operations like adding a new content type should be a dropping new
> class in content.py file (think Django). However, I don't see how we are
> going to achieve this in long run with the current Plone codebase which is
> mess of ZCML, .py and GenericSetup XML registrations
I actually think code generators tend to hinder adoption and
understandability more than they help. Better to have well-documented,
cross-referenced examples ("You also need to update ...") and work to
simplify the stack (think Dexterity, and its use of martian).
> * 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.
> * I will disagree with everyone else what kind of code skeleton file
> layout etc. we should we have, but eventually I am right :)
I think we should aim for simplicity, first of all.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Product-Developers