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.  

Imagine this:

the 'plone' template currently has a 'template_dir' that points to 
zopeskel/templates/plone.  That folder looks like this:

plone
        +namespace_package+
                +package+
                        __init__.py_tmpl
                        configure.zcml_tmpl
                        profiles
                                default
                                        metadata.xml
                        tests.py
                docs
                        INSTALL.txt_tmpl
                        LICENSE.GPL
                        LICENSE.txt_tmpl
                setup.py_tmpl

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 
like this:

abstract_gs_profile
        +namespace_package+
                +package+
                        profiles
                                default
                                        metadata.xml

Then, our plone structure above could be simplified like so:

plone
        +namespace_package+
                +package+
                        __init__.py_tmpl
                        configure.zcml_tmpl
                        tests.py
                docs
                        INSTALL.txt_tmpl
                        LICENSE.GPL
                        LICENSE.txt_tmpl
                setup.py_tmpl

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:

abstract_license_gpl
        +namespace_package+
                docs
                        LICENSE.GPL
                        LICENSE.txt

abstract_license_mit
        +namespace_package+
                docs
                        LICENSE.MIT

abstract_license_bsd
        +namespace_package+
                docs
                        LICENSE.BSD

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' 
property.

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:

advantages:
* increased flexibility
* better ability to change the overall filestructure of a template based on 
user input 
  (improves our ability to build templates that contain only what they 
want/need)
* improved ability to have single locations for the 'canonical' implementation 
of a given 
  set of files and directories

drawbacks:
* more complexity required to figure out where all the stuff in a template is 
coming from
* makes it a bit harder to create new templates as you need to understand the 
system


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,

Cris

********************************
Cris Ewing
Webmaster, Lead Developer
Department of Radiology Web Services
University of Washington
School of Medicine
Work Phone: (206) 616-1288
Cell Phone: (206) 708-9083
E-mail: cew...@u.washington.edu
Web: http://www.rad.washington.edu
*******************************

_______________________________________________
ZopeSkel mailing list
ZopeSkel@lists.plone.org
http://lists.plone.org/mailman/listinfo/zopeskel

Reply via email to