Ticket #10874 (closed PLIP: wontfix)
Convention Based Plone Theming
Reported by: | eleddy | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | 4.1 |
Component: | General | Version: | |
Keywords: | theme | Cc: |
Description
Proposer:eleddy
Seconder: None as yet
Motivation
Basic theming in Plone is too hard, especially people coming from other web/design frameworks. Anyone should be able to come into the product and just want to apply a theme: by "theme" I mean resources such as css, javascript, and images. People coming from small web projects expect this structure - why not provide it?
From a PSC perspective, themes in Plone are a sore spot. Hopefully a structure that is familiar will encourage more designers to create and contribute nice themes. Furthermore, small and simple packages open up lots of opportunities for theming on the fly a la blogger, posterous, etc...
This feature is targeted at small to medium size projects who don't need the complexity of a theme product or xdv, and especially plone novices.
Assumptions
- Not looking at customizing templates, viewlets, etc... A significant gain can come from just allowing resource based themes. This will limit the scope and complexity making it more likely to be released in the next release.
- Plone is moving towards an emphasis on XDV and then later Deco, meaning template customizations will increasingly become less important. If this happens as planned, modifying things like footers won't be template based anyways.
- Large customizations that require template changes will continue to use addons like z3c.jbot or create their own theme.
Proposal & Implementation
- Move away from an egg format and back to a drop directory like Products used to be. User should be able to unzip 1 or more themes into a folder and install the themes, ideally without restart. This convention over configuration is a benefit instead of a liability since it's general web convention, not just plone. It would be something as simple as:
- themes - theme1 - config.something - static - images - javascript - css - theme2 ...
- The decided conventional layout will take into consideration future integration with xdv
- Resources are automatically registered with reasonable defaults. Any customizations from there go to the ZMI or a product
- When running in debug mode, changes are detected automatically as it works now
- config file will contain only basic information like theme name, author, and version. It will be a human read/write format, since it's simple and written/read by humans first and foremost (not XML, for example).
- Theming can be based on a "naked" plone site, with custom still taking precedence in layer selection.
Deliverables
- Unit tests
- Documentation
- Set of themes out of the box for kick starting new projects/themes, based on common plone user theming goals
Risks
- There is no buildout story here.
- Scope creep, with the potential to make things too complicated and/or configured.
- I would like but don't yet know the answer to the question of making a theme be "based on" another theme. For example, maybe someone wants sunburst but with 3 css changes. The best example is all the css for the javascript popup overlays - when stuff is naked it looks terrible, then there is a lot of work to overcome there. I think this is going to be a simple as "start with a copy of the other theme". This makes sense when integrated with things like theme editor.
Participants
eleddy
Progress
Change History
comment:2 follow-up: ↓ 4 Changed 6 years ago by eleddy
Fantastic idea. The main reason everything is in a "static" directory was to enable just that with rewrites if needed. Ideally, is Plone going to be running with by default in 4.1?
comment:3 follow-up: ↓ 5 Changed 6 years ago by optilude
A few concerns (condensed iPad version)
We can't lose RR merging and URL mangling. It's a critical feature of Plone. Solutions without this lead to gotchas in the deployment stage of a project.
I think we should integrate this with XDV at least optionally. CSS and JS is never enough. You need some kind of markup solution. It wouldn't be too hard and I know Laurence has been thinking of something like this.
Is there an implementation design or is this just wishful thinking at this stage? The implementation has some nontrivial aspects.
Could this start as an add-on product? I think it's a high risk thing if we're not 100% comfortable this is the right long term solution.
Martin
comment:4 in reply to: ↑ 2 Changed 6 years ago by hannosch
Replying to eleddy:
Fantastic idea. The main reason everything is in a "static" directory was to enable just that with rewrites if needed. Ideally, is Plone going to be running with by default in 4.1?
Unfortunately there is no PLIP to either "enable" WSGI for 4.1 or make it the default yet. My guess is that we are going to see more community exploration of this, once the basic technology is there in Zope 2.13 for everyone to use.
comment:5 in reply to: ↑ 3 Changed 6 years ago by hannosch
Replying to optilude:
We can't lose RR merging and URL mangling. It's a critical feature of Plone. Solutions without this lead to gotchas in the deployment stage of a project.
I'm not sure I agree. I think there is a subset of simple Plone sites which could do without these. Once we have WSGI and a "normal" web server is part of our stack, I think we could offer a story around it. This would work best for sites, which have only one persistent Plone site per database and don't need a lot of the overhead we have for the fully customizable stack.
Of course there's a danger in advertising this and not having a seamless upgrade path to more sophisticated setups. Maybe we first need to play the WSGI game a bit more and overhaul ResourceRegistries as a WSGI endware. There's at least five different approaches to resource handling and dependency management in Zope and Grok and more in the general web world. It's a bit of a chicken and egg problem though: Should we first enable a static theme solution and drive the demand for a new resource handling solution as a consequence or should we wait for that new solution to be written, which nobody wants to do, as it has no practical application yet.
Is there an implementation design or is this just wishful thinking at this stage? The implementation has some nontrivial aspects.
I think we are using the PLIP process to facilitate discussions on design these days. We don't really do this on the general plone-developers list anymore. So it's perfectly acceptable to propose a not fully fleshed out idea and get community feedback on the general idea and direction through the framework team process. The PLIP process is a two step process these days, where an actual implementation is only required for the second stage. I can fully understand anyone who wants to get positive feedback on the general direction first, before committing to the full implementation. This might end up in the PLIP being deferred to a later 4.x release if the implementation falls short.
comment:6 follow-up: ↓ 7 Changed 6 years ago by optilude
Hi Hanno,
RR merging and URL mangling is an important feature, and a Plone differentiator. I'd be very uncomfortable recommending as "good practice" anything that loses this. The problem is not just the speedup of fewer requests. When you deploy a site and subsequently make changes, you need a unique resource URL so that people don't get "old" CSS/JS cached in their browsers.
That said, I don't think it's impossible to have a solution that integrates with RR, e.g. by implicitly adding these resources to the end of the merge list (or just above ploneCustom).
Re implementability - I was mostly just curious. It's perfectly valid to discuss this without a detailed implementation plan at this stage.
My gut, non-FTW feeling is that it's a bit risky integrating anything like this that hasn't been tried in the wild. The large number of "rc" releases for collective.xdv is testimony to how many subtleties there are in theming and visual customisations. I also feel pretty strongly that the sensible thing to do would be to keep XDV as an optional part of this picture, if only to gain from the momentum it has. The latest XDV releases are actually really powerful and elegant.
I could see a solution where:
- You load an egg that is configured with a directory to look for themes in (I'm not sure how it knows where to look, though, if not inside a deployed egg with an entry point)
- In this directory, you have an "ini" config file + subdirectories ala what eleddy proposes above
- The package registers the 'static' directory as a ZTK resource directory
- It also implicitly registers CSS and JS resources in the respective RR registries (will require an extension point in RR)
- You can list CSS and JS ids from portal_css/portal_javascripts that you want to disable when the theme is in effect
- If you want, you can optionally specify an XDV rules file in the config file, through which you can apply rules, transforms and select a theme (XDV now supports themes referenced in the config file syntax)
- You go to a control panel in the Plone site to select + enable the theme (ideally should be the current themes control panel)
This gives a pretty gentle learning curve. You start by dropping some CSS files into the right directory to move things around. When that becomes too limiting, you can use XDV rules to work with the markup.
Some implementation thoughts:
- I'd be good if the config file syntax was pluggable (e.g. different [sections] would be managed by different plugins). This way, XDV integration could be a plugin. We could even have a z3c.jbot-type customisation as a future plugin.
- I'd still like this to start as a separate package, but maybe we need an "enabler" PLIP e.g. to get some hooks into RR for this.
Martin
comment:7 in reply to: ↑ 6 Changed 6 years ago by hannosch
Replying to optilude:
I could see a solution where:
[...]
The solution Martin outlines sounds to me like exactly the kind of complicated tight Plone integration most people don't need and won't understand.
I'd love to see something more along the lines of:
- You configure two WSGI apps in your wsgi config file. One for the Plone backend and one for the static resource directories.
- The static resources are served directly by a web server without needing Plone integration, requiring ZODB database access, transactions or any of the other overhead.
- A WSGI middleware like repoze.squeeze or a similar approach sits in front of the static resource WSGI app to provide merging, unique url generation and generally caching improvements.
On the technical side the person using this only needs to understand the wsgi config file but no Python knowledge, eggs or any component architecture is involved. This approach is much more similar to the deployment approach used by other web applications.
The main question is how such an approach would provide an upgrade path to more sophisticated setups that need "Plone theme" configuration inside the Plone application, theme layers, template customization or any other advanced setup. My gut feeling is, that there are enough sites out there, that would be happy to live without all this and welcome the simplicity of just being able to drop some files into the file system.
comment:8 follow-up: ↓ 9 Changed 6 years ago by optilude
Hi Hanno,
The point of this is surely that people shouldn't need to understand how it's integrated with Plone? They just dump the right files into the right directory.
My suggestion was a thought experiment on how we could make this work with current technology. I agree that a more WSGI-oriented solution would be nice, but I don't think we can ship with that unless we (a) have an official WSGI story and (b) have a tested, stable answer for things like resource merging and "unique URL" invalidation, including a migration story.
If we want this kind of theming for 4.1, the dependencies above sound pretty steep. Maybe we could start with something a little bit less ambitious that could evolve on the backend into something like what you propose, which really shouldn't matter to users.
I'd be pretty strongly opposed to something that wasn't integrated with our other standard solutions. We have enough duplication and learning curve "cliffs" already around theming. If we came up with something that's 50% easier to understand up front and 50% harder to evolve from, we're still at net zero, plus lots of new code to maintain. Surely we've learned this lesson by now?
For the same reason, I think XDV needs to be part of this. In fact, the "standard" XDV pattern as described on http://pypi.python.org/pypi/collective.xdv is pretty close to what is being described here, but with the added requirement that you have to create a Python egg and do some boilerplate ZCML configuration. I know Laurence wants to find a way to make a simple XDV theme installable without that boilerplate, with something every similar to what Elizabeth is proposing, so maybe those two things become one. One nice thing with the XDV approach is that if you really don't care about resource merging, you just put <link /> and <style /> tags into the theme HTML, which is pretty straightforward. :)
Martin
comment:9 in reply to: ↑ 8 ; follow-up: ↓ 10 Changed 6 years ago by sergey_v
Replying to optilude: Are "members of public" entitled to comment on the PLIPs? :)
I have a feeling that the idea is kinda going against "there should be one way of doing things" principle... moreover, it's like if we had bicycles with triangular wheels and somebody proposed using square wheels - they still don't ride well but hey, some people may like square wheels more :)
What worries me here:
- we're throwing away all distribution/packaging benefits which come with eggs - versions, metadata, pypi, using them with buildout etc.
- how the distribution is going to happen? Will we just exchange .tar.gz files and unpack them manually into themes/ folder? Will I need to copy a theme manually from my dev machine to the server? Will somebody then invent a way to automate this, effectively re-inventing eggs, buildout and the rest of the infrastructure?
- if installing eggs is difficult/error prone, shouldn't we look into improving that instead? Something similar to, say, Ubuntu software centre where one will be able to browse for eggs marked "plone theme" and install them with a single click? We could build a buildout recipe which, say, enables all eggs located in a specific folder without manually listing them in the buildout config. Then dropping an egg there and restarting the server would be enough.
- if creating an egg is too difficult, could we provide a paster template/a button in plone control panel which just creates a new egg in themes/? Then a developer goes to the filesystem and adds the files to the pre-created folders
- there's no way to transition from a 'theme' to a proper egg-based skin product (i.e. imagine you've created a theme by customizing css and then you realize you need a small template tweak... or to add a simple portlet - a classical "ZClasses trap")
- The proposed functionality can be replicated by just placing stuff into a custom folder in portal_skins. I'm even sure that the ability to tweak css/javascripts/images through-the-web is more appealing to novice users than just placing files in a hard-to-find folder on a filesystem of a remote server usually running Unix novice users are often not familiar with. This TTW customization ability used to be a huge selling point of Zope/Plone.
Can the proposed functionality (only better) be achieved by just adding some tools to facilitate, say, uploading/downloading the contents of a folder in portal_skins as a zip file? We could also add a function to export it to the filesystem by creating a 'theme' egg in themes/ and dumping the folder contents there. We could even have some hooks so whenever a css/js file is added to the folder it is automatically registered with a resource registry.
If we build a nice control panel for that which allows to add a stylesheet and do some quick tweaks to the running Plone site's theme, then dump the changes to the filesystem and, say, add a couple of portlets that'd be awesome. And I think it would require less effort to implement as all the bits are already here.
comment:10 in reply to: ↑ 9 ; follow-up: ↓ 12 Changed 6 years ago by eleddy
Replying to sergey_v: I don't want to interrupt the flow of arguments too much because this is great, but I do want to elaborate the use case this satisfies. This is the person who gets an installer, runs it, and then shows up on #plone because they want to use a theme [product] and the answer is "well... you have to learn buildout for that". It's kind of a bait and switch, and that's why I put this as a PLIP instead of a add on product. Not that we shouldn't talk about it, but in my experience this user isn't going to be sophisticated enough to care about multiple deploys or maybe they just want to do a fast prototype for a potential client.
Anything involving an egg from the end user perspective is contrary to the spirit. The custom folder allows people to make their own themes but not install others easily, so that's also not ideal.
Zopeskel is great but it's not maintained with Plone which is scary to depend on (I heard rumors about PLIPing that as well?). Zopeskel is a solution to a symptom wrt theming anyways. If the end solution really is simple, transitioning to a real product wouldn't actually be that difficult. A theme product is an egg with a skins folder that looks almost exactly like the structure described. In fact, I would say you make a zopeskel template to do the transition from a simple folder based structure to egg, if and when needed, using zopeskel (or something like it). That would be a great transition from novice to intermediate/advanced development.
Building on what sergey said, I really like the idea of uploading eggs/tars or whatever from the front end if that is needed to trigger machinery. It's great because it avoids the access to the filesystem issue as well, and customization can continue as usual in the custom folder. It can also pave the way to do cooler things like installing remote themes.
wrt the xdv integration - I don't see xdv as a requirement to implement, but rather a next step. The problem with relying on the link method is that you need a link to a stylesheet behind a server, which in many cases is zope itself, so it doesn't make anything easier. That being said I am curious what the overhead of doing both at once might be. Everything I'm hearing is that XDV is the theming story for templates - maybe they go more hand in hand than I realize. I'm not an XDV ninja so I'm happy to have guidance here.
Agreed on the waiting for the wsgi story. For what it's worth, I am really excited for it too!
Thanks for all the great ideas and discussion everyone! I really think this is something that end users would appreciate, even if it's not the easiest to implement :)
comment:11 Changed 6 years ago by optilude
Hi Elizabeth,
Have a look at: http://pypi.python.org/pypi/collective.xdv#a-worked-example
It'd be possible to achieve this with convention-over-configuration so that there's no ZCML/GenericSetup config except maybe some metadata.
So, in this case, a theme becomes:
- Create a new theme directory in the "themes" folder
- Add a boilerplate rules.xml file. As of XDV 0.4, this can reference the theme file with a <theme /> directive. Let's say the boilerplate has <theme href="theme.html" /> which means "find the theme.html file in the same directory as rules.xml. You may also want some stock rules like dropping Plone's CSS by default, and mapping the main content to a standard div in the theme with a default it ("content").
- Add a theme.html file that references css/*.css, js/*.css and images/*.jpg. Build this using Dreamweaver or whatever. Test it locally off the filesystem. Make sure it looks and feels as you'd like. Make sure you use the documented HTML ids (e.g. "content" for the main content).
- Start up Plone. Go to the theme control panel. It's found your theme. Click "enable". Your theme shows up.
The good thing here is that your theme work starts by building a static version of what you want the site to look like. You can do that with zero knowledge of Plone. When you then see the theme with Plone stuff mapped in, you'll need to add some more CSS to deal with the Plone markup that's showing through, but this is limited to only the bits of markup you actually use.
The downside of this approach is that there's no easy way to do a "just CSS" theme. That said, I'm sceptical that that's ever useful, even for very simple themes. If your needs are that simple, the "custom" folder is probably enough.
Martin
comment:12 in reply to: ↑ 10 Changed 6 years ago by sergey_v
Replying to eleddy:
Replying to sergey_v: Not that we shouldn't talk about it, but in my experience this user isn't going to be sophisticated enough to care about multiple deploys or maybe they just want to do a fast prototype for a potential client.
Chances are that user also is not sophisticated enough to deal with scp'ing files to the server, changing permissions etc. Chances are high the user doesn't even have access to the filesystem of the server but still would like to try some themes. TTW themes would make much more sense in this case.
Anything involving an egg from the end user perspective is contrary to the spirit.
Not if there's a button "Create a new theme" which creates an egg. But anyway, if a user is able to ssh into a server and run 'tar zxf ./mytheme-0.1.tar.gz' - I suppose they'll be able to run 'paster create -t plone3_theme megacool.theme' or 'easy_install somebodyelses.theme' - I really see no difference here.
If you really don't like all that boilerplate code in eggs - setup.py is about the only file which is required and it can be made really minimal, so even creating it from scratch is not much work - not more than creating a 'human-readable' config for the 'theme thing'.
The custom folder allows people to make their own themes but not install others easily, so that's also not ideal.
We could add some UI to export/import stuff or install it from an 'app store' - those actions will just create folderish 'theme objects' in portal_skins.
I really feel that we should either stick with existing and proven distribution formats (eggs) or keep the stuff in the ZODB (with possibly an option to dump it to the filesystem as an egg)
Zopeskel is great but it's not maintained with Plone which is scary to depend on (I heard rumors about PLIPing that as well?). Zopeskel is a solution to a symptom wrt theming anyways. If the end solution really is simple, transitioning to a real product wouldn't actually be that difficult. A theme product is an egg with a skins folder that looks almost exactly like the structure described.
So why use a directory-based 'theme thing' if you can have a proper egg with just a couple extra files, which were generated by a paster command anyway? Having a proper egg has lots of benefits wrt distribution, versioning etc. - why give up all this?
comment:13 follow-up: ↓ 14 Changed 6 years ago by optilude
Thinking about what Sergey has said, here are some alternative thoughts that may meet some or all of both his and Elizabeth's concerns.
At the moment, collective.xdv lets you specify a URL to an XDV rules file and an associated theme HTML with its own resources. There is no restriction on where these live. The "best practice" in the c.xdv docs suggest you deploy them as a resource directory in an egg that you install, and that you ship with a GenericSetup profile that configures c.xdv to use this theme.
However, the theme can also live in the ZODB, or even a filesystem directory (although associated resources obviously need to be published somehow). This means we could have something like this:
- The current XDV control panel settings move to a secondary "External" tab
- The primary tab contains a list of "Internal" themes that c.xdv knows about.
- Next to the list, we have three buttons: Import, Export and Create New.
Behind the scenes, c.xdv manages a folder in the ZODB, e.g. /themes. Each theme in the "internal" list is a sub-folder here, which, by convention, has a rules.xml, a theme.html and subdirectories for css/, js/ and images/. So, we could have:
/plone/themes /plone/themes/mytheme /plone/themes/mytheme/rules.xml /plone/themes/mytheme/theme.html /plone/themes/mytheme/css/*.css /plone/themes/mytheme/js/*.js /plone/themes/mytheme/images/*.jpg
When the user clicks "Create New" and chooses a theme name, a new skeleton theme directory is created. This should contain a useful basic rules.xml and associated theme.html which just maps the most common Plone markup, e.g. the content and the main navigational aids. It can also have a simple placeholder css/style.css.
The user can now edit this theme through the web, using simple textareas where he can edit/paste in HTML, CSS and XDV rules (deja-vu, I know).
As an alternative, the user can develop the theme using the "External" feature, giving a filesystem directory with the same layout.
The "Export" and "Import" button allows ZIP archives of theme directories to be exported or imported. This becomes a simple sharing and deployment mechanism. You zip up the theme and then import it in the target site. Of course, you can just as easily unzip on the filesystem and list the filesystem URL in the "External" tab.
Some advantages of this:
- XDV has decent mindshare by now and a fair amount of real-world testing. This has thrown up a number of subtle issues that XDV has solved, and which any other theming solution is likely to run into (e.g. what do you do about pages where you shouldn't have the theme applied, like the overlays or TinyMCE dialogues)
- It's easy to get started - it requires nothing more than a running Plone site with c.xdv installed.
- No filesystem access is required for basic theming.
- There's a simple deployment/sharing story.
- We can still deploy more advanced themes in eggs, using the python:// URL scheme implemented in c.xdv. Existing XDV theme packages will continue to work.
- You can still use resource merging in RR if you want to, at the most basic level by using the ZMI.
- The pieces are already there. The "only" thing that's needed is the UI work.
Martin
comment:14 in reply to: ↑ 13 Changed 6 years ago by eleddy
Replying to optilude: I love it. I'll sit down with XDV this week to try and better understand any potential issues. This is a great story that accommodates several types of development styles.
Anyone have any concerns about integrating collective.xdv into the core? I know this requires lxml - could there be compile/setup issues there? I suppose it can't get worse than PIL.
comment:15 follow-up: ↓ 16 Changed 6 years ago by optilude
Why don't we figure out if we can make it work first, and then worry about whether it's "core" or not?
lxml does get worse than PIL, by the way, but the problems are surmountable. I'm not 100% convinced this needs to ship with Plone just yet, but that doesn't mean we can't build this and make it a recommended way to do theming.
Let's find out if it really works in practice before adding it to the core. We've been wrong before.
comment:16 in reply to: ↑ 15 Changed 6 years ago by eleddy
Replying to optilude:
lxml does get worse than PIL, by the way, but the problems are surmountable. I'm not 100% convinced this needs to ship with Plone just yet, but that doesn't mean we can't build this and make it a recommended way to do theming.
This was my initial fear for adding xdv functionality as part of this particular PLIP and why I wanted to delay that until later.
Let's find out if it really works in practice before adding it to the core. We've been wrong before.
Ok, I just want to make sure that SOMETHING happens to the theming story. I really need to sit down and thumb through the xdv code to see what is actually happening there. Maybe it can be modularized to accommodate theming without xdv even.
comment:17 Changed 6 years ago by optilude
My personal gut feel - and people may disagree here - is that anything that is "just" CSS and JavaScript is too limiting to be useful. I think the next step up is "placeholder-based" theming, which is basically what XDV delivers.
One thing you may be interested in - I'm rewriting Chapter 8 (theming) of my book to cover XDV-based theming. That's how much I believe in it as a model, and it will likely lead to more uptake of this approach. If we could have a nice "TTW" theming story, then that's an even bigger win.
There's nothing wrong with shipping c.xdv, but I'd rather see this evolve properly outside the core, on a shorter release cycle, and then be integrated when we feel it's working well. Part of that evolution may be making sure that installing c.xdv becomes very simple.
The lxml issue is just a technical thing that can be overcome. I wouldn't let that stop us.
comment:18 Changed 6 years ago by ldr
(This comment seems to have turned into a rambling collection of loosely connected points, oh well.)
- I'm really glad we're having this discussion. Plone really needs a new theming story, and one that has a gentle learning curve. I quite like the themepack name that someone (either Jon or David) came up with on IRC a while ago.
- I do think there is a place for simple CSS/JS/images only themes, especially for intranets where all you may need to do is change the logo and a few colours. XDV comes into its own when you are creating a public site or working with HTML/CSS that someone else has created.
- I don't think eggs or paster are the way to solve this, at least not yet. Maybe in the future when distutils2 is fully baked and we have a setup.cfg rather than a setup.py this might be worth revisiting.
- Should themepacks support basic template customization? That would allow plonetheme.classic and plonetheme.sunburst to become themepacks rather than eggs. Downside is we have two very different types of templates, in skins and views.
- Mozilla's JetPack packaging guide has similar motivations and is worth a read.
- Here's my themepack thought experiment
- I think this should perhaps be allowed to develop outside the core for a bit longer, but maybe renaming it to plone.app.theming (or something similar) at an appropriate point and look to making it an official part of Plone in 4.2 or 4.3.
what do you do about pages where you shouldn't have the theme applied, like the overlays or TinyMCE dialogues
We just set X-No-Theme response headers on these templates. That should work for both collective.xdv and Apache, though Nginx will need some more work.
comment:19 Changed 6 years ago by esteele
- Status changed from new to closed
- Resolution set to wontfix
This PLIP has been declined for consideration for Plone 4.1.
Framework Team voting on this PLIP was: Alec +0 Craig -1 Elizabeth -- Laurence +0 Martijn -1 Matthew -1 Rob -1 Ross --
Framework Team discussion centered around the idea that in general, we should be exploring ways to improve over the status quo of theming, but there is a danger in introducing yet another way to do theming rather than consolidating. The recommendation is to create the proposed functionality as an add-on first.
Maybe we could build this on top of the WSGI support we will get with Zope 2.13 (likely in 4.1).
This would allow us to serve all these directories directly from a web server without going through Plone. That should be a lot easier then dynamically registering the files as resources and delivering them through the Zope process.