Have you ever made an announcement and then realize how many things you left out? Well, here is the follow up to yesterday's announcement.

Big omission:

when we released, we forgot to upgrade the demo site http://us.demo.enfoldsystems.com/ . While  Enfold Desktop worked just fine with the older demo server, the more advanced features of the 4.5 version were not available,  which meant users were not seeing all the new features.  That oversight has been corrected.

One  misconception is that Enfold Desktop works only with Plone. 

This is half-true.  Desktop 4.5 works fine as a standard Webdav explorer.  We do not support this mode (i.e. don't ask for help),   but it works just fine.  In fact, I would like to see Enfold Desktop being picked up by other Content Management Systems.    

I use Enfold Desktop with mod_dav, Zope and Plone.  You can also browse Subversion. 

Try it: https://svn.enfoldsystems.com/public 

Unfortunately something is borked.  You cannot GET/PUT from DAV/SVN.  GET/PUT *does* work on mod_dav without Subversion.  Since this is not support its at the bottom of the queue.

A feature that may not be so obvious:  Scriptable context menus.

  Did you know you can add context menu's to Enfold Desktop using CMF Actions?  That's right.  Through the Web interface (portal_actions) you can actually add context menu's to your end user's Desktop!  This functionality has been there for years.  But until our documentation overhaul it was never documented. See http://www.enfoldsystems.com/software/desktop/docs/4.0/extending.html
 

If the software is not licensed the end user will see banners.

I will give you an example of two banners we added on launch of Desktop 4.5.

 

 
  The banners revolve around the Plone community and Enfold Systems product lines.  Maybe in the future we could have "Vote for Plone at Pact Publishing in 2009?"  If enough people used Enfold Desktop - we could empower end users to Vote!

Which brings me around to final question. 

Would you like Plone to ship with Enfold Desktop?  Do you think Enfold Desktop is a differentiator to other Open Source CMS?  Do you think the introductory text for Plone should talk about Enfold Desktop?  Our numbers show only about 5% of the total people downloading Windows Plone installer know about Enfold Desktop. 

• Should we add Enfold Desktop to the Plone Windows installer?  i.e. at the end of the installation notify the user they can have a Desktop integration?
• What's your thoughts?  Please bring them up on plone-users and on your blogs.
• Do you think more people would use Plone if they knew Enfold Desktop worked out of the box with Plone?

Over at Enfold Systems we have made two releases this week: Enfold Desktop and Enfold Proxy.  The release numbers indicate a "maintenance" release,  but  in fact significant enhancements and bug fixes were made to both products.  While Enfold Proxy is 100% commercial the same is not true for Enfold Desktop.  This post focuses on Enfold Desktop and the Plone WebDAV story.

Download Enfold Desktop

What's  New about Enfold Desktop 4.5

Quite a few things that have changed.  The big ticket items are listed below.

• A summary of what's new is described at:  http://www.enfoldsystems.com/software/desktop/new-desktop
• Windows Vista is now supported.  On Windows XP/2003/Vista 64bit versions will now work with Enfold Desktop.
• When a WebDAV does a PUT on an existing resource, the item is now versioned.
• WebDAV now triggers events that can be acted upon by Content Rules.
• If you WebDAV DELETE a document which  break a  links; link integrity will generate valid XML response.  Enfold Desktop will actually  prompt you and notify you of this breakage -- you have to see this feature.. (it's awesome).

Misconceptions about Enfold Desktop 4.5

While talking to people on #plone there were  some misconceptions about Enfold Desktop that  ought to be cleared up.

• Enfold Desktop comes in two parts.  The client (Enfold Desktop) and the server components.  The client will only run on Windows.  BUT, the server components are cross platform.  If you are using WebDAV with Plone, regardless of platform you should absolutely be using Enfold Desktop server components.
• Enfold Desktop licensing.  The licensing is quite simple.  If you use Enfold Desktop client and you are not licensed there will be tasteful ads displayed at the bottom of the explorer menu.  If you do not want the ads,   simply purchase a license.  That will not only remove the ads but also entitle you to support.  If you haven't upgraded,  you will see a "New Desktop Available" badge on top of the banner ads.  Even if you are not purchasing the software, you can still help  by upgrading to the latest version of Enfold Desktop.

Getting the Software

The software comes in several flavors.  

• Enfold Desktop client.  This is the Windows Explorer shell integration (written entirely in Python) that end users install on their computers.
• Add-on Installer for Python 2.3 or Python 2.4.  These are Windows installers for Plone or Enfold Server.  Simply click to install them on the server.
  
• Add-on Archive for Python 2.3 or Python 2.4.  These are tarballs for any platform.  Simply uncompress and copy to Products folders.
• Buildout recipe.  https://svn.enfoldsystems.com/public/desktop/release/4.5/

We have gone the extra mile to make it easy for integrators to  install and use Enfold Desktop for  their Plone projects.  We hope this brings more attention to the WebDAV story on the Zope/CMF/Plone platforms.  We have also overhauled  documentation for all of our products, including  Enfold Desktop. If you want to ask usage questions, Mailing list for Enfold Desktop is also available:  http://lists.enfoldsystems.com/mailman/listinfo/community-desktop .

Do your part to give folks something to talk about over beer in D.C! Sign up to give a lightning talk.

It's a tradition at Plone Conferences to hold lightning talks at the end of each day. These are lively, short talks on just about anything of general interest. Recruit for your sprint, show off your product, show off somebody else's product, tell us how you get something useful done.

Sign yourself up for a talk at the lightning talks page on the conference planning site. Do it soon. The slots usually fill. Then, start practicing your fast talking.

We were lucky enough to get together at the New Orleans Plone Symposium several people who care about and work on the installers. Ian Anderson, Joel Burton, Alexander Limi, Sidnei da Silva and I spent a few hours brainstorming concrete improvements that could be made in a short time. Several of these are now available in experimental versions of the Windows, OS X and Unified (Linux, BSD, OS X, Solaris ...) installers for Plone 3.1.4.

All are available at http://plone.org/products/plone/releases/3.1.4 . Look for “Experimental.”

Please try them out and file bug reports and improvement suggestions to http://dev.plone.org/plone -- under the appropriate “Installers” category.
Highlights of what’s available and what’s coming:

Buildout

Sidnei’s put together a buildout-based version of the Windows installer, and I’ve gotten one going for OS X, which means that all the major platforms now have a buildout capable installer.

OS X

The new version of the OS X binary installer (only available at the moment for Intel and Leopard) now has installation options including cluster or standalone and admin or user installs; it also allows you to set the Zope admin password on installation. And, it has some pretty, new Plone icons.

Unified Installer and OS X Binary

Some of the new features that are (more or less) implemented in the new “ex” OS X and Unified installers:

• A new “bin/plonectl” shell script will start and stop all Zope components
• The installed buildout.cfg files start with commented-out example add-ons for popular and development products. (The framework team will make the final choices.)
• Also in the installed buildout.cfg:
• A commented-out "unpinned" Plone definition
• buildout.cfg should have more comments and better order
• The default install will filter deprecation warnings by default. Developers may turn them back on.
• paster and ZopeSkel are managed by buildout, so that they may be updated easily.
• The default install path for the Unified Installer is now /usr/local/Plone; the OS X installer /Applications/Plone. We’ve removed the version suffix because the in-place update capabilities of buildout make it less meaningful.
• The old default page at the root of the ZODB is replaced with one that mentions Plone. (This will be refined before the 3.2 release.)

I recently wrote a buildout recipe that some Plone folks might find useful.  One of my current OpenPlans-related tasks is improving our caching and load-balancing setup.  After a bit of research I decided to start serious testing with Varnish for caching and nginx for load-balancing.  Since both of these have decent buildout recipes from which to start, buildout was a natural choice for a build and deployment management tool.

One of buildout's strengths is that, ultimately, all you need is a single buildout.cfg file to define your entire deployment.  You can then check this file into a VCS repo somewhere, and you (or anyone else) can replicate the entire software stack with one checkout from the repository and one command.

When using buildout, however, I frequently found myself checking out the same buildout.cfg file and then tweaking it slightly, to change such values as port numbers, host names, and passwords, from deployment to deployment.  This was annoying to do, and left me with uncommitted local changes that I had to take care not to commit back.  Neither was I excited about the prospect of managing the versioning for each of these buildout.cfg files separately, when the only thing that varied between them was minutiae.

topp.recipes.cfgtemplate eases this process by allowing you to specify variable substitutions in your buildout.cfg file.  Here's how the plone.recipe.plone recipe (echo?) config file might look:

[buildout]
parts = cfgtemplate plone zope2 instance
eggs =
develop =

[cfgtemplate]
recipe = topp.recipes.cfgtemplate

[plone]
recipe = plone.recipe.plone

[zope2]
recipe = plone.recipe.zope2install
url = ${plone:zope2-url}

[instance]
recipe = plone.recipe.zope2instance
zope2-location = ${zope2:location}
user = {{admin-userid}}:{{admin-password}}
http-port = {{http-port}}
debug-mode = {{debug-mode}}
verbose-security = {{verbose-security}}
eggs =
    ${buildout:eggs}
    ${plone:eggs}
zcml =

products =
    ${plone:products}
    ${buildout:directory}/product

Note the use of {{double curly-braces}} around variable names in the [instance] section.  When the user runs buildout against this file for the first time, she will be interactively prompted to enter the values for these variables, which will then be stored in a cfgsubs.cfg file for use during subsequent builds.  The settings persist, but the buildout.cfg file itself is not changed.

The recipe sort of abuses buildout at the moment by claiming to have installed a file even though it didn't, so that buildout will re-install the part (i.e. perform the value substitutions from cfgsubs.cfg) every time.  There's probably a better way to do that.  It's proven immediately useful, however; here's the buildout.cfg for our nascent Varnish and nginx build setup.

As a follow-up to my "what's new with Salesforce PFG Adapter (i.e. Plone/Salesforce.com integration as made possible by PloneFormGen)" entry and screencast, I also needed to make some video on a newer project called RSVP For Salesforce for Jon's use at the latest Plone Symposium. I think the aforementioned project page on Plone.org provides a decent overview of its current features and limitations, but of course a screencast is always more indicative of how it's used. 

Hope you enjoy:

NB: While not quite as mature as our PloneFormGen integration code, RSVP for Salesforce has happily pulled in a bunch of online registrations for an upcoming workshop ONE/Northwest is hosting called Strategy and Best Practices for Action Alerts and Other Email Communications.  I'm hoping to improve the ease of configuration before we use this more widely.

On a final note, this is an interesting problem space because, as mentioned in the video, the promotion of an event, capture of participants, and ongoing interaction with attendees required by event registration really weaves back and forth between tools for managing content and for managing constituents.  An aim to solve this with one tool seems a recipe for an inflexible monolith, which will lead to an inevitable compromise in features and functionality.  Having such capable systems as Plone serving as the CMS and Salesforce.com the CRM seems like such a natural separation of concerns where the sum is so much greater than the parts.  Marrying the tools together took a fraction of the time and effort required to build even a subset of the functionality from the ground up.  That is something I find endlessly exciting.

PloneFormGen is due for some refactoring to take advantage of Zope 3 and Plone 3 technologies. But meanwhile, I've taken the opportunity to integrate a couple of handy new contributions.

Ratings-Scale Field

Titus Anderson of the University of Louisville has contributed code for a Likert Scale Field. I've renamed it to be "Ratings-Scale Field" to use a  more common name and reflect its more general usability. This field supplies a table of question rows, each with radio-button answers.

Saved-Data Editor

Andreas Jung contributed an editor for saved data. Switch to the tabular view of your saved data, and you'll have a new option to individual items.

Egg Cooked

This was actually added in 1.2.3. PFG is now available as a PyPI egg. Just add Products.PloneFormGen to the eggs section of your buildout . Jens Klein's great ScriptableFields have also been cooked into eggs and declared as requirements for the PFG egg; so dependencies are automatically handled!

Sprint Planning

I'm hoping to make PFG refactoring a sprint topic at the 2008 Plone Conference. If you're interested, visit the planning page for details and sign up. Andrew Burkhalter and I have been scheming for a possible earlier sprint that might lay the technical foundations. Let one of us know if you're excited by that idea.

-- Steve McMahon

It's been a while since I've written an update on the progress that's occurred leveraging the fantastic PloneFormGen to save form responses directly within Salesforce.com and the aforementioned article (though still a good source of background information now has several factual inaccuracies.

The 1.5 branch of the code base has seen a couple of initial releases and offers the following features, which I've enjoyed using on some of the sites we've deployed:

• "Parent"/"Chained" adapters - There's now a simple UI and functionality for related record creation within Salesforce.com.
  
• Support for file uploads (typically stored as an Attachment record related to some other record within the CRM system)
  
• Better handling of dates
  
• A whole host of other minor bug fixes
  

Of course, it's always better to see, rather than read what I'm talking about.  The following screencast consists of a pretty advanced example that demonstrates all of the aforementioned features and then some:

Thanks to Jon Stahl, who presented on the above at the latest NOLA Plone Symposium.  Without his refusal to demo this live, creating these videos would likely still be on my todo list.  Hope you enjoy!

With the release of Plone 3.2, all the major Plone installers will be buildout-based.

The Unified Installer is already buildout-based, and there are experimental buildout-based binary installers for Windows and OS X available on launchpad.net. The Windows and OS X installers will not require installation of a compiler.

This represents a watershed event for the deployment of Plone: buildout will be our mainstream product installation system. What was once a technology for developers will have become a technology for integrators.

If we're to make Plone's installation story as good as possible for integrators, this is going to require some adjustments by add-on product developers.

• It's time to eggify your products and upload them to PyPI. It's amazingly easy to do so, and there are several examples in the collective that you may use as models. Look in particular for the Products.* products like Products.Clouseau, Products.PloneSoftwareCenter, Products.PloneHelpCenter and Products.PloneSoftwareCenter. Most of these are simple updates of existing products. You may still (and for some time, should) create old-style tarball distributions from the same codebase without much extra work.
• Strongly consider putting your eggified product in the Products.* namespace to simplify installation. That's currently the easiest way to avoid the need for ZCML slugs, which are incomprehensible to many integrators. If you're converting an existing product, it really belongs in the Products.* namespace so that code that imports it doesn't break.
  
• Once that's done, update your installation instructions to document installation with buildout. It's a lot simpler than the old method.
• Don't tell folks to use your buildout. That's a fine idea while a product is in development and the development team needs to have the same environment. But, it's the wrong thing to tell an integrator. Tell them how to add your product to their buildout with as few side-effects as possible.
  

6/4/08 - New Orleans

    The symposium was kicked off at 9:30AM CST this morning.  There are two tracks: developers and business.  The conference attendees are of an interesting blend: the business track has about 30% of the attendee's. The development track ranges from sophisticated production environments to point-and-click salesforce integration.  The symposium will last 2 days. Each evening all the attendees will meet up to have food and drinks at a
local bar. And of course there will be music after 10PM at the venue. Enfold Systems hosted the conference with sponsorships from Diamond Data Systems, Six Feetup and Gocept Consulting.
    So far the big news has been that the Plone Handbook for End Users has been released for Plone 3.x. Free under the creative commons and will shortly be available in hard copy at Amazon.com in the United States.  You can find the book at http://plonebook.info/ -- check it out!  A few other tidbits.
    Enfold Systems has announced the releases of their product line. The Microsoft Web Server integration, Enfold Proxy 4.0 (commercial product) with support for Vista with numerous bug fixes and a complete documentation overhaul.  Enfold Desktop 4.0, now *FREE* is available in its final form. And the release candidate for Enfold Server 4.0 which ships with Plone 3.1.2 and a complete overhaul of documentation. 
    The new enfold systems website has been launched!  It uses Enfold Systems content deployment platform, Entransit.  *VERY* interesting.  And demonstrates Enfold System's committment to the content deployment platform.  Check out the website and let us know what you think! http://www.enfoldsystems.com/
    Desktop 4.0 final offers a superior user experience to past versions and Enfold Systems has committed to merging all DAV/Server component patches to the Zope and Plone platforms.

Wow, it's been a while since I've sent a message out to the greater Plone community.  I've been a bit busy over the last few months, what with having a new baby, and with internal-facing improvements to the OpenPlans software.

In the last weeks, though, I've been able to get around to some long-lingering needs which may be of interest to all of you.  Specifically, I've been getting the OpenPlans software to work on Plone 3.0, and I've put some finishing touches on the OpenPlans installation process, so that it's now much much easier for someone who wants to play around with a full OpenPlans stack to get started.  (OpenPlans, for those of you who don't know, is the largely-but-not-exclusively Plone-based software that powers the collaborative community website openplans.org, among others.)

The Plone 3 support is still experimental; it's not deployed on any of our live sites, and it hasn't yet seen any extensive testing.  It installs and works, however, and all of our unit and functional test suites pass.  And not only do they pass... they run much more quickly.  The zopectl tests are about 2.5 times faster (yes, that's 250%!) than they were before.  The flunc tests, which emulate a browser and connect to a running site over HTTP, don't see that much of an improvement, but they are consistently 20-25% faster than they are against a Plone 2.5-based stack.  Much (but far from all) of the improvement comes from Helge's refactoring of Membrane's object_implements index implementation; if you run a Remember or Membrane based site and you haven't played around with that code, I strongly recommend you do.  In any event, once we get this merged back to the trunk and installed on the openplans.org site, I'm confident there will be a very noticeable performance improvement for our users.

Equally exciting to me is that we now have some nice tools in place for people to get their own local copies of OpenPlans working.  It's taken us three iterations, but we've finally got a set of build tools and a build process dialed in that is working for us in managing both our development and production deployment environments.  And we've put some thin wrappers around this to make it easy for you to get started.  You can learn more at our getting started page.  If you're REALLY impatient you can eyeball the steps you'll have to take to get things going in the quick start section, although you'll probably also want to look at what you will need since OpenPlans does require that some other tools and services be available on your server before you can start the build.

Those of us at TOPP have had a great time building this; we hope that you find it valuable, and that you have as much fun using it, either hosted by us on openplans.org or as your own installation elsewhere.

Yeah, I know that Jon already let the Sightline Daily cat out of the bag and every day brings ever more impressive and interesting Plone sites, but before I move onto the next project, I'll afford myself a few minutes to get nostalgic.  Thanks for humoring me.  I figure anything that consumes several hundred hours+ and a few months of your life deserves at least a blog post for posterity.  Plus, I'm happy with the result.
 

So, in no particular order, here are several of the noteworthy pieces that make up Sightline Daily:

• I suppose the first thing anyone notices in a site is the graphic design and, *man*, is Sightline Daily tastefully done.   It's clean, skimmable, attractive, and presents a lot of metadata about news clippings in a non-overwhelming way.  A few times, I found myself mindlessly clicking around and just absorbing the niceness.  Sightline Institute managed the design process with Ryan Swarts and it's a great product.  My colleague David Glick implemented the CSS to perfection with some initial bootstrapping and work by ONE/Northwest friend Trey Beck.
  
• By ONE/Northwest standards, there was a rather large team collaborating on this project.  Sightline brings ~10 content editors, bloggers, content creators, and project managers to the table.  On the implementation side, we teamed with Web Collective (they focused on the blog features and portlets mostly, while I did the daily news headline-related programming), bringing the number of programmers, templaters, specification writers, and CSSers to 8.  On top of the implementation work I was responsible for, I had great time working with my fantastic co-worker, Kelley, helping to manage the biggest team I've worked with to date.
  
• I believe Jon mentioned the bookmarklet for clipping headlines, but this is fantastic.  It's the fastest method I've seen for *manually* pushing content into Plone.  Leading up to the implementation, I was a bit nervous about this piece, but equipped with a similar snippet produced for Salesforce.com by a co-worker, Steve, some inspection of the del.icio.us bookmarklet, and some Googling about, this was a cinch.  You have to see the screencast below to get a sense for how it works.  Money quotes from Sightline Daily editor Kristin Kolb were "You're saving me from carpal tunnel" and "I feel like I just received my Christmas present early" (I first demoed this in early December) upon seeing this. Awesome.  I couldn't make that up.
  

• Auto-generation of related items based on a Plone catalog query for 2 relevant news headlines and 1 blog post.  The effort to navigate to and hand pick related items was too time-consuming for the editorial process, so we wrote code that takes into account key terms to use for a query of Plone's "SearchableText" index and creates references to the returned results.
  
• A wizard-esque configlet that logically steps through the entire publishing process from choosing the date for the next "edition" of news clippings through to bulk editing all the way to previewing and publishing for site visitors.  The entire process can be done outside the context of the normal Plone user interface.  The highlight is definitely the bulk edit screen (seen to the right), which allows for starring news headlines as "top picks", editing of the keywords that should be used for auto-relating items, and drag 'n' drop reordering of stories.  Kudos to Jon for brainstorming a solid, implementable specification for this that held pretty closely from mockup to implementation.

• It's been said before, but Zope 3 brings us a fantastic event system.  The bookmarklet mentioned and screencasted above uses Javascript to get the current browser location and pre-populates the news headline with a permalink.   There's no need to slow the clipping down by forcing the editor to manually type or select the source publication as well (i.e. The New York Times or Washington Post).  Rather, site users manage a centralized list of publications (new publications are added organically over time) using ATVocabularyManager.  Using each object's permalink and Python's urlparse, we simply index the permalink's netloc for fast retrieval.  With this, we can compute and index the publication automatically.  This is where Zope 3's event system comes into play.  Because ATVocabularyManager fires off custom events upon edit and deletion of vocabulary terms, our headline's source publication stays up-to-date with some super simple event handling code.  Thanks to the kind soul that baked this capability into ATVocabularyManager, because I wasn't going to port AT-events back from Archetypes 1.5.x.
  
• Once launched and under normal load, the site turned out to be unexpectedly fast thanks to Cachefu and some minimal configuration effort.
• The site includes a nice bit of tasteful, interactive Javascript, again mostly implemented by my colleague David Glick. One can quickly expand and collapse the headlines and toggle between the days of the week. This makes the site highly skimmable.
  
• Every morning, Sightline sends out the top 10 or so headlines via email.  In the past, one manual effort involved populating the site, while another involved drafting the daily email for a blast out to subscribers.  This was a flat out waste of time and when you mix in how temperamental email clients are about HTML in email, this was a drain on Sightline staff.  ONE/Northwest often uses an ASP-based email broadcasting service called WhatCounts for the "email newsletter" part of our projects.  This service provides an incredible feature called "Smartget" (and it's near identical siblings "cacheget" and "get" -- which I like to call "Dumbget").  After the morning publishing process is finished on the site, Sightline logs into their WhatCounts instance and are greeted with a 1-line email template that goes out and grabs the raw HTML contents of the following page showing the latest news.  Prefer plain text email, yeah, we did that too.  No double entry at all.  My colleague Sam, did a fantastic job of giving me a plain-old HTML template that was cluttered with the most nasty HTML tables and inline styles needed for a consist look in the wild world that is HTML email compatibility.  I don't think in HTML 4 and tables, so this was a huge boost.
  
• Clean urls for news by topic, news by region, and rss by whatever.  I have an unreasonable hatred of nasty urls.  Try passing the following out over the phone http://www.domain.com/some/path/page?query_param=@value@&query_param_2=value2&template=some_template.htm.  That's not even social.  Thanks to Plone, we almost never have to worry about this.  Before this project, I had never noticed the "subpath" (update: I intended to write "traverse_subpath" here, not "subpath" -- sorry if that threw anyone off.) parameter that's available in Zope's request.  Essentially, you can add whatever directory structure onto the end of a skin-based template and it's right there for your consumption as a Python list in the request's subpath.  I do a bit of processing in a browser view and instead of things like ?topic=energy, we have the following clean, friendly urls:
• daily.sightline.org/news/topic/energy
• daily.sightline.org/news/region/washington
• daily.sightline.org/rss/topic/energy/region/washington
  
• In my opinion, Sightline's best content is their in-depth blog entries that are part of a series.  They've done great ones on bicycle neglect and the quest to go an entire year carfree.  Brian and Justin of the Web Collective put together a basic "series" content type and extended the blog entry, so that in the context of a blog post, the author can assign an entry to an existing series.  This isn't rocket science, but it works really well for Sightline's needs and the graphic design for a series object is one of the best templates on the site.
• Tests, tests, and more tests.  I insisted before development started that because this application was so critical to the organization, because it was fairly complex with significant code interaction, and because there was a decent sized team of folks that had no clue what other developers were doing, that we needed to embrace a test driven development approach and push as much presentation logic into easily testable Zope 3 views.  I even convinced myself that we had budgeted correctly for it ... oops.  Test driven development is paradoxically both time consuming and time saving.  At the end of it all, I don't regret the decision to adopt this approach one bit.  I doubt few do.  At the time of this writing we have 399 unit tests and all of them pass but 1, which I left unfinished to remind me of a feature I couldn't get working within the bulk admin interface and therefore disabled entirely. I wanted to finish that, but it was unnecessary and I needed to move onto other scoped items.  The fact that we still have entirely passing tests after site launch for the enabled features signifies that even as we approached the looming deadline, we didn't abandon our agreed upon approach.
  

So, there you have it.  I suppose I could write another post or two covering all the lessons learned and the endless details that went into getting this site launched, but for now, I'll leave things at that.  It's best to reflect on what worked well in the end anyways.  Furthermore, I think Jon still plans to do a case study and possibly a screencast about the editorial process.  That will certainly be interesting and take a closer look at the big picture.

I've been using zc.buildout for a few months now, and am quite happy with it.  However, I got tired of navigating to my egg cache, locating the right package (and version) within a long flat list, and then clicking a few more times to actually get to the contents of the package.  And I was looking for a project to practice my buildout recipe fu.

So I created collective.recipe.omelette.  It's a simple buildout recipe that takes all your namespace-packaged eggs and merges their contents together into a single directory tree, in its own parts directory, with symlinks to the actual egg contents.  The result looks much the lib/python of days gone by.  So instead of:

egg-cache/
    my.egg.one-1.0-py2.4.egg/
        my/
            egg/
                one/
                    (contents of first egg)
    my.egg.two-1.0-py2.4.egg/
        my/
            egg/
                two/
                    (contents of second egg)

you can now make use of:

parts/
    omelette/
        my/
            egg/
                one/
                    (contents of first egg)
                two/
                    (contents of second egg)

with obvious advantages in navigability and greppability.

Collective.recipe.omelette is available from the Cheese Shop.  You can add an omelette to your buildout by making the following additions to buildout.cfg (assuming you have a part called instance and you want to generate symlinks for its eggs), and then re-running your buildout:

[buildout]
...
parts =
    ...
    omelette

[omelette]
recipe = collective.recipe.omelette
eggs = ${instance:eggs}

One caveat: Since this makes use of symlinks, it of course won't work on a filesystem that doesn't support symlinks, such as Windows'.