On 21/03/2012, at 7:12 PM, Martin Aspeli wrote:
Hi,
On 21 March 2012 04:50, Mikko Ohtamaa <[email protected]>
wrote:
Hi Martin & co.
On Tue, Mar 20, 2012 at 20:35, Martin Aspeli <optilude
[email protected]> wrote:
On 20 March 2012 17:15, Mikko Ohtamaa <mikko
[email protected]> wrote:
Hi,
I have created a new Plone add-on code skeleton based on Plone 4.1,
five.grok:
https://github.com/miohtama/sane_plone_addon_template
It is not based on any template engine: just clone and go. Tries to
be as
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 course.
* 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.
With collective.hostout they don't even need the step of deploying out
of source control. That would require them to setup their deployment
environment, install the source control etc on the production server
etc. Instead hostout packages and uploads their development eggs for
them directly into the remote server buildout cache, as well as
setting up the remote server with the buildout they are using. No
source control required.
bin/hostout host bootstrap <- to get the server ready for buildout
bin/hostout host deploy <- to replicate their buildout to the remote
server + upload packages.
BTW: I think the plone-customizations idea is a great simplification
for beginners. It might create bad habits but it's one less thing they
have to learn upfront which is a big plus.
I'd suggest hostout could be a good addition to something like devstart.
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 place.
* 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.
Martin
_______________________________________________
Product-Developers mailing list
[email protected]
https://lists.plone.org/mailman/listinfo/plone-product-developers
_______________________________________________
Product-Developers mailing list
[email protected]
https://lists.plone.org/mailman/listinfo/plone-product-developers
