Hi Cris, I'd say this is the way to go. Removing stuff if not needed did work, but it is error prone as we have seen. Yes, it will be a bit harder to understand, but one needs to understand how it works anyhow. Cleaning up templates and making them more DRY will improve quality and consistency.
Do you know if there are any abstract templates that would conflict? - Roel On Thu, Jun 24, 2010 at 1:35 AM, Cristopher Ewing <cew...@u.washington.edu>wrote: > 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 > > -- Roel Bruggink http://www.fourdigits.nl/mensen/roel-bruggink Four Digits BV http://www.fourdigits.nl Willemsplein 44, 6811 KD, Arnhem tel: +31(0)26 4422700 fax: +31(0)84 2206117 KVK 091621370000 BTW 8161.22.234.B01
_______________________________________________ ZopeSkel mailing list ZopeSkel@lists.plone.org http://lists.plone.org/mailman/listinfo/zopeskel