Hi all, apologies because this one's gonna be a bit long. . .
an issue that was reported today to the zopeskel tracker
(http://plone.org/products/zopeskel/issues/46) got me to thinking about how we
can implement a more flexible, reliable and configurable way of building
directory and file structures for our zopeskel templates.
Here's the issue:
At the moment, each and every template we have has one an only one
'template_dir' which is the source of files and directories created by the
template during the run loop. Templates can indicate that other templates are
'required_templates', which then mean that the 'template_dir' for those
required templates are also run through when creating the directory structure.
An example of this is the 'archetypes' template, which declares 'plone' as a
required_template, and thus inherits file structures from plone--such as the
'tests.py' file. It is worth noting that the archetypes template has an
explicit post-run cleanup step where it removes this unwanted file.
This post-run cleanup is how I fixed the issue linked above. I simply added a
profiles directory to the plone template_dir and then added a 'post' method to
the plone template that attempts to remove it if no profile has been
registered. This works, but it strikes me as exceptionally inelegant.
I'm wondering if there might be a better way.
What I propose is a setup where we have a number of modular 'structural
templates' which provide no new vars, no extra information, just file and
folder structure. We could then utilize the 'required_templates' property as a
plug-n-play system for adding and removing these structural templates.
the 'plone' template currently has a 'template_dir' that points to
zopeskel/templates/plone. That folder looks like this:
What if we were to abstract the tree ending in the 'profiles' directory and its
content to a new, abstract, structural template, call it something like
'abstract_gs_profile.py' and create a new template directory for it that looked
Then, our plone structure above could be simplified like so:
and in plone.py, we can create a 'pre' method that checks to see if the
'add_profile' var is 'True'. If so, then we add the 'abstract_gs_profile'
template to the list of required_templates and a profile is added when asked
for, instead of being deleted when not asked for (like is currently done).
Here are some more places where this might help:
Issue #30 in the zopeskel tracker:
(http://plone.org/products/zopeskel/issues/30). We allow folks to choose a
particular license (at least in some templates). However, because all of the
templates in which this is set up inherit from the plone template above, which
has the GPL in place, choosing a different license has zero effect. You get
the GPL or nothing. Not very friendly.
The way things are right now, that's not something we can fix. There is no way
to conditionally choose which files in a 'template_dir' to create and which to
leave behind. However, with the above proposal we could create a series of
abstract license template_dirs like this:
and so on. Then a template which allows the user to select a specific license
could use the 'pre' method to implement a bit that checks the value of the var
and inserts the appropriate template name into the 'required_templates'
I can also see this as a way to solve the problem of supporting different
testing frameworks for various versions of Plone. We could allow folks to
choose between a 'tests.py' file, a tests folder based on the current ZTC/PTC
framework, a tests folder aimed at the new testing package optilude is working
on, or whatever.
Basically, it winds up like this:
* increased flexibility
* better ability to change the overall filestructure of a template based on
(improves our ability to build templates that contain only what they
* improved ability to have single locations for the 'canonical' implementation
of a given
set of files and directories
* more complexity required to figure out where all the stuff in a template is
* makes it a bit harder to create new templates as you need to understand the
I'm writing this because I want to gather some input from the folks out there.
Are there things I'm missing in this analysis? What haven't I thought about?
Is there a better way of doing this?
Thanks for your input,
Webmaster, Lead Developer
Department of Radiology Web Services
University of Washington
School of Medicine
Work Phone: (206) 616-1288
Cell Phone: (206) 708-9083
ZopeSkel mailing list