Hi,<br><br><div class="gmail_quote">On 21 March 2012 04:50, Mikko Ohtamaa <span dir="ltr"><<a href="mailto:mikko@opensourcehacker.com" target="_blank">mikko@opensourcehacker.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Martin & co.<br><br><div class="gmail_quote"><div><div>On Tue, Mar 20, 2012 at 20:35, Martin Aspeli <span dir="ltr"><<a href="mailto:optilude%2Blists@gmail.com" target="_blank">optilude+lists@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><br><div class="gmail_quote"><div>On 20 March 2012 17:15, Mikko Ohtamaa <span dir="ltr"><<a href="mailto:mikko%2Bplone@redinnovation.com" target="_blank">mikko+plone@redinnovation.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
I have created a new Plone add-on code skeleton based on Plone 4.1,<br>
five.grok:<br>
<br>
<a href="https://github.com/miohtama/sane_plone_addon_template" target="_blank">https://github.com/miohtama/sane_plone_addon_template</a><br>
<br>
It is not based on any template engine: just clone and go. Tries to be as<br>
minimal as possible. Instructions provided.<br></blockquote><div> </div></div><div>Cool ;-) </div><div><br></div><div>Did you have a look at the 'plone-customizations' egg provided by plone-devstart? Wondering if it serves a somewhat similar purpose.</div>
<span><font color="#888888"></font></span></div></blockquote></div></div><div><br>I checked out plone-customizations egg and some other stuff which was pointed out for me on this mailing list and elsewhere.<br><br>I was just wondering if the following goals where possible to achieve the minimum barrier of entry for new Plone developers<br>
<br>* 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.<br>
</div></div></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div>
<br>* 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.<br>
</div></div></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div>
<br>* 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.<br>
</div></div></blockquote><div><br></div><div>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.</div><div><br>
</div>
<div>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.</div>
<div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div>
<br>* 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 <br>
</div></div></blockquote><div><br></div><div>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).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div>
<br>* 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.<br>
</div></div></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div>
* I will disagree with everyone else what kind of code skeleton file layout etc. we should we have, but eventually I am right :)<br></div></div></blockquote><div><br></div><div>I think we should aim for simplicity, first of all.</div>
<div> </div><div>Martin</div></div>