Design Goals (Discussion)

[tisto]

Design Goals

• Simple is better than complex.
• Cover 80% of use cases, don’t become too complex.
• Provide a good starting point for development, not a swiss army knife for the entire development cycle.
• Code and tests should reflect the current coding best practice.
• Generated code should have 100% test coverage.

Concrete Decisions

• Do not use local commands. They significantly increase complexity and mr.bob has no support for them anyways. We tried this with ZopeSkel/Templer and it did not work out that well.
• Limit the overall number of questions to not confuse people too much. Having separate packages or providing commented out code sections might be a good alternative.
• Fix problems in Plone itself rather than providing workarounds in our templates. (see https://github.com/plone/bobtemplates.plone/issues/27)
• Provide skeletons for the most important Plone package use cases, not for every possible scenario:
  • Add-on product (collective, plone, custom project, policy product)
  • Content Types (Dexterity, Archetypes?)
  • Theme

This is just a draft and open for discussion. Feel free to comment or propose additions. I would especially like to hear the opinion of @cewing and @smcmahon. If we can reach an agreement we can add those design goals to the docs.

[aclark4life]

FWIW, IMHO:

• Kill the term "product" once and for all. Use terminology "package" to refer to "thing you add to the buildout" and "add-on" for "thing the package provides".
• PLIP bobtemplates.plone for inclusion in the Plone core so it gets "first class support". (Including it in the core does not guarantee it will be supported, but the best experience I've had with template/code generators is in Django/Pyramid where its obvious the core team put some thought in to the experience.)
• 100% code coverage for generated code is nice, but not strictly necessary. For the most part, anyone running a code generator is not going to care about test coverage for their generated code. And if you are generating enough code to require tests, something else is probably wrong and should be fixed in Plone itself (as per concrete decision 3).

[do3cc]

Would it make sense to use branches to provide optional addons? That might make it simple to keep in sync with the base package.

[pbauer]

• Focus on Plone 5 (no old-school js-registration, only Plone5-style).
• Test against Plone 5
• +1 for shipping it with the installers
• We could even include it in Plone itself. There are two places where exporting customosations as a package is usefull:
  • Dexterity: Additionally to "Export type-profile" we could "Create addon package with type"
  • Something better than https://github.com/plone/plone.app.themeeditor that exports customized templates/images/css/js as jbot-overides in a package
• No local commands.
• No additional skeletons or branches until bobtemplates.plone is really really stable.
• We could instead discuss changing the "Add demo view"-question to "Add demo content, views and configuration" (default: False) and then add a type with a python-schema, a view (for it), a viewlet and some other things that are considered best-practice (js and css-registration). Depending on that question we could even then query for the name of the type.
• Always include a profile and drop the question about that (there are very few cases when you don't want a profile and none of them applies to beginners)

[tisto]

I went ahead and created a pull request where I removed all questions that are unnecessary in my opinion (profile, setuphandler, testing, version, locales, keywords):

https://github.com/plone/bobtemplates.plone/pull/43

I also created issues for every question I removed, so feel free to comment there if you think we should keep one of those.

With five basic questions left (name, email, github user, package description, plone version), I think we should in addition just ask if the user wants to create a theme or a dexterity package (or a "basic" pkg).

[davisagli]

You can probably get name and email from the user's git config. But it's not that bad to ask for them.

[do3cc]

:crying_cat_face: https://github.com/plone/bobtemplates.plone/blob/master/bobtemplates/hooks.py#L75

[pbauer]

Why is that cat crying? The already build-in feature to get name and email from git works.

[gforcada]

My feeling is that we are in maintenance mode already, at least for series 1.x, so if the design goals have to change, that would be a 2.0 release anyway.

Closing...

[tisto]

@gforcada I don't understand you comment. I think the discussion here went a bit away from the original intend. Design goals are a set of rules that we use as a base line for all further discussions. I think we can just add the design goals to the README and then close the ticket afterwards.