There were lots of conference discussions — and a fun exchange of rants during lightning talks — about the state of Plone's installers. Also, lots of good ideas exchange recently on the Plone Foundation Members list.

I wanted to share the high points of an open-space discussion on the topic. Thanks to David Bear for taking notes.

We identified several goals and champions:

Installations should include common layout/tools/buildouts

Except where the platform prevents it, the outcome of an installation on major platforms should look pretty similar. There should be the same set of directories inside the install, and pretty much the same tools in bin. The buildout .cfg files should be largely the same, and the current Unified Installer .cfgs are a good base implementation.
Champion: Steve McMahon

Our installers should be in a common repository

Plone is an open-community project, and we need to have as many people as possible feeling that they can file tickets and fix bugs. That means having them all in the same vcs repository — with no barrier to fixing bugs beyond filing a contributor's agreement.
Champion: Steve McMahon

Use a templating system to generate the .cfgs for different platforms

This would help maintain just a single buildout .cfg set for all the installers.
Champion: Cris Ewing

Installers should be part of the continuous integration testing

We can't test all platforms (why would we want to), but we should be able to use jenkins to routinely test installers against new plone versions on Windows, OS X and a couple of flavors of Linux.
Champion: Eric Steele

QA Testing

A QA team is getting organized, and testing installers on multiple platforms is a great chore for them.
Champion: Liz Leddy

Visual Controllers are a huge problem

Apple's unexpected abandonment of wxPython in Lion, and the unlikelihood of a timely development of an independent Lion-compatible wxPython 2.6.x leave us with a mess.
Unfortunately, trainers have been getting increasing feedback that many newer OS X and Linux users are not command-line comfortable, so we still need the visual controller functions, and may need them to do even more.
Mikko and Craig are going to check out alternative visual scripting environments that might be cross-platform. Limi is asking if we could product an HTML/JS controller with something like a thin python http server to do the real work. That's feasible, but there could be some real security analysis needed.

David Bear's Notes:

------------------------------------------------------------------
- unified installer and buildout
- Open space discussion
------------------------------------------------------------------
same buildout.cfg all platforms	Steve
same repository ->			Steve
templer buildout for .cfgs 		Cris 
Automated  tests in jenkins 		Eric
QA - platform testers -- 		Liz
Visual Controller (qt?)  		Mikko 
(xampp)

Yesterday marked the release of PloneFormGen 1.7b6. I anticipate that we'll have a release candidate shortly. The bigger news, though, is that I finally got some time and moved the PFG version control repository to Github. You'll find it at https://github.com/smcmahon/Products.PloneFormGen.

Pull requests will be welcome. But, if you're a regular contributor (or think you might be a regular contributor), drop me a note and I'll add you to the collaborator list.

I also opened a new issue tracker at https://github.com/smcmahon/Products.PloneFormGen/issues. There are two reasons for switching away from the old issue tracker:

• The social features of github are fun and easy to use. Using the github issue tracker gets all that integrated with the code repository.
• The old issue repository had gotten to be a mess. That was partially because I didn't get e-mail notifications of new issues for several months. On checking in, I found that many issues in the tracker were long fixed and it was very slow updating them.

Martin Aspeli's Professional Plone 4 Development is the most-anticipated Plone book since Martin's earlier Professional Plone 3 Development. For Plone developers, it pretty much goes without saying that Martin is an outstanding technical writer, and that his documentation of Plone's development environment is definitive.

What got my attention about PP4D was that the contrast between it and PP3D is very much like the contrast between Plone 4 and Plone 3.

Plone 4 does more than Plone 3, and Martin's book is bigger and has new chapters and sections to cover the new features. But Plone 4 is also sleeker and faster than 3. Its parts fit together better, and it's more approachable to new users and integrators.

Martin shows us that the same is true for Plone 4 development. Both the Plone 4 development environment and the PP4D book make more sense than their Plone 3 counterparts. The parts fit together better. Plone 3 development required that you know, and practice, both new (Zope 3 style) and old (Archetypes) development paradigms. You had to know how to use Python packages and Zope products, skins and browser views. And, I think the Plone development community (and Martin) were not really sure how these fit together and when it was best to use which.

PP4D is much more confident. Dexterity (content-type development framework) and Diazo (theming system) are much better ways to develop, and Martin is able to explain them clearly without having to burden the reader with so many layers of history. PP4D, like its predecessor, is still a book for experienced, versatile programmers, but it doesn't need to make as many apologies to its audience.

Professional Plone 4 Development is thus a better book than its predecessor in part because Plone 4.x is a better development platform. Martin's community leadership is — of course — a large part of the reason for this advance. But, the improvements are also due to the great work of the many folks on the core development and framework teams.

So, Martin should take a big bow. But Hanno Schlichting, David Glick, Laurence Rowe, Eric Steele, Denys Mishunov, Rob Gietma, Alex Limi and many others should be proudly joining that curtain call. Bravo.

This year's training offering for the Plone Conference brings together some of the best teachers in the Plone community. The training topics are great, but even if you think you're already a wizard in all the class topics, you might want to sign up for a class anyway just to spend a couple of days in a classroom with one of these instructors. They'll not only teach you techniques; they'll also help you organize your Plone expertise. The line up:

Martin Aspeli is our community's most prolific writer, the author of Professional Plone Development, and its forthcoming update for Plone 4.1. Behind the scenes, he's responsible for many of our new framework components and sets the standards for our testing tools. Want to move up to the ranks of Plone development/deployment masters? Spend a couple of days with Martin.

Paul Everitt is a walking encyclopedia of Zope technologies. He's also a legendary speaker and comedian. Paul's students are not only going to get a good, practical introduction to Pyramid; they're also guaranteed to have a great time and learn stories that will have folks buying them beers for years.

Chris Ewing is a tremendously thoughtful and generous teacher. As leader of the ZopeSkel project, he's also been spending a lot of time thinking about how to make it easier to get going with Plone add-on and theme development. Cris puts the same kind of effort into class preparation. You can be sure that he's going to teach the best and easiest way to do things, and explain it well.

Chrissy Wainwright's students from her past Plone Theming classes have a shared secret. They know that Chrissy has distilled years of solid experience of designing and implementing Plone site designs into an amazing two-day package that will help you solve nearly any real-world design implementation problem. Some of the best Plone themers I know have walked out of Chrissy's classes dumbfounded by all the new things they learned.

Steve McMahon (yes, me!) I'll just say that I work hard to make my classes valuable and enjoyable. You can be sure that I'll be well-prepared and will have thought hard about how to keep you awake and amused, as well as informed. I've taught at four prior conferences or symposium, and think I'm getting better at it each time. I first taught Dexterity at this year's Plone Symposium East.

I've always had mixed feelings about PloneFormGen’s Fieldset Folder feature. There are some nice things about it — like the ability to move a whole fieldset with a single operation — but also annoyances, like needing to drill down to move fields within a fieldset.

More fundamentally, I don't think it’s an intuitive mechanism for PFG's target users. When you’re visually designing a form, a fieldset is a presentation feature, and not necessarily a unit of functionality.

In any case, the Fieldset Folder mechanism now has another problem: it works very poorly with the “quickedit” feature, which was introduced in PFG 1.6 and much enhanced in PFG 1.7 thanks to Manca's GSOC work. I suppose that could be fixed with a large helping of new JavaScript and a lot more visual complexity, but the point of PFG is to be simple (or at least as simple as possible).

So, PFG 1.7b4 has a simple-minded solution. We now have “Fieldset Begin” and “Fieldset End” items that are just markers. All they do is start or end a fieldset. The “Begin” is a little more elaborate as it allows you to set a label and description. The “End” doesn't even have a label.

So, drag them from the toolbox; move them around the form; delete them. All they do is start and end visual fieldsets.

Fieldset Folders are still available, and work as before. You just won't be able to maintain them from the quick editor.

Hope you like the new facility!

I've just released two new versions of PloneFormGen:

1.6.1 is a maintenance release for the PFG 1.6 series. It contains several bug fixes made over the last few months, but no new features. Thanks to Maurits and David for fixes, and to MJ for a Norwegian translation. It works in Plone 3.x and 4.x.

1.7b1 is the first beta release for the 1.7 series. It's big new thing is Manca's work on drag and drop and quick editing of fields. Drag and drop support is now picked up from collective.js.jqueryui. 1.7 will run on Plone 3.3.x or 4.x, but will be most comfortable on Plone 4.1, which includes an updated plone.app.jquerytools. If you want to use 1.7.x with Plone < 4.1, make sure you add a pin to your buildout to specify the latest plone.app.jquerytools.

Also, I just release a new version, 0.2, of Products.PFGDataGrid. This merges Nathan Van Gheem's Plone 4 compatability branch. It should work with Plone 3.x or 4.x.

Our sprint was held Friday and Saturday, November 26th and 27th, in a beautiful room atop the Windsor Hotel Tower. We had a great view of central Córdoba, and the city's great energy helped keep us in good spirits.

SteveM, Emanuel Sartor, and Chimera all worked on PloneFormGen. Most of this was around merging Manca’s GSOC branch, which adds great new UI to PFG. Work on this included:

• Branching PFG; trunk is now 1.7dev
• Merging Manca’s GSOC branch
• Adapting to use new plone.app.jquerytools kit
• Making the new JavaScript pass jslint tests and generally cleaning it;
• Making a JS message translation framework, since there are now several messages in the JavaScript.
• Revising the new browser view that discovers fields to make it more generally useful going forward.
• Researched jquery tools drag and drop functionality to see if it can be more generally used in PFG (unfortunately, probably not);
• Worked on PFG quick edit bugs in new code.
• Stripping old Plone 2.5 compatibility code (PFG 1.6+ doesn’t support Plone < 3.1);
  

We got several people up to speed on buildout and bug fixing, and participated in the Plone TuneUp. Emanuel, Diego and Franco fixed bugs.

Roberto Allende worked on his ZODB class browser; he found a good JS library to render panes.

Juan Diaz worked on collective.thememaker with chimera; working on project to be committed to collective.

Talk submissions are now open for Plone Conference 2010, and your Plone company may be starting to encourage folks to submit talk proposals.

Please, think beyond just coders! We'll have a more interesting, and more valuable, conference if we bring together all the kinds of skills and interests that make up the Plone project. So, please, encourage your user-interface, design, theming, user-documentation, and project-management folks to put in talk proposals and to attend the conference.

Some talks I'd love to see:

New Horizons in Accessibility. OK, Plone's accessibility isn't bad. What can we do to make it better? Not just in the accessibility-checklist sense that so many are fixated on, but in the opening new possibilities sense.

Instrumenting Usability. Usability testing is great, but are there good ways to instrument our sites to find UI failure points? Do we have any case studies on bringing that sort of data to bear on design?

Customized Documentation. Has anyone got good mechanisms that their team uses to customize documentation for end users with customized sites?

Managing multi-national, multi-cultural projects. Plone has got some good i18n tools, but that's probably the tiniest consideration in making a project with diverse participants successful.

Constituent-relationship case studies. There are lots of Plone sites in use by advocacy organizations that organize constituent campaigns. How do they use existing Plone tools to make that work. What more is needed?

Delivering content to low-tech communities. We're adding on slick AJAX UI with every release. Is that posing a problem for getting information to folks with old browers and slow connections?

That's just my list. The point is that agile organizations bring directly together coders with the people who have domain knowledge. Realistically, we're not going to have lots of end-users at a tech conference. But we can get together a larger portion of our own tech community if we think beyond the set of those who write Python in preference to their birth tongue.

In a recent post, I described some of the great work Nenad Mancevic (Manca) has been doing adding new user interface features to PloneFormGen as part of his Google Summer of Code project.

GSOC 2010 is now complete, and it's time to show you something moving! Here's a quick tour of some of the new features.

Hopefully, Nenad will be able to make it to Bristol for the Plone Conference, and we'll all be able to let him know personally how much we like his work.

Google's Summer of Code Program offers students around the world the opportunity to do some paid summer work for open-source projects. It works by pairing students and experienced project mentors. GSOC has been very good to the Plone project over the years; we've had several students every summer.

This summer, I'm working as a mentor with Nenad Mancevic (Manca), who's adding some great new dynamic User Interface elements to PloneFormGen. PFG's a generic form builder for Plone that's aimed at end users and site admins: it allows them to quickly build simple forms to do simple things like record or e-mail input.

PloneFormGen uses the Plone interface for adding and maintaining content. The advantage of that is that it gives users a very familiar interface for building forms. But that's meant that it lacks a lot of form-oriented niceties to help out more proficient users.

Nenad is using jQuery, jQuery Tools, and a little jQuery UI to add some dynamic form-editing tools that power users will really love. Let's take a quick look at some of what he's already got going. You may check out Nenad's work in detail by taking a look at his svn branch, which is currently working with Plone 4.

Widgets Manager

When you click the "quick edit" flag on a PFG form, the first thing you'll notice is a new "Widgets Manager" displaying all the form fields and actions you may add to the form. Nenad had to dive pretty deep into Plone and PFG to find a way to grab a list of all of the PFG types which may be added at a given location by a given user. (Remember, there are lots of third-party field and action add ons for PFG that need to be included automatically.)

The Widget Manager is going to allow Nenad to offer a drag and drop mechanism for adding new fields and actions to a form.

Speaking of Drag & Drop

PFG's quick editor has been using some code repurposed from the Plone folder reordering mechanism. It had some oddities, and offered little user feedback. Nenad's replaced it with some new, very slick functionality imported from jQuery UI. (A minimal import that doesn't drag in any of the bigger chunks of jQ UIs behemoth bulk.)

AJAX Inline Editing

When you're making a quick change to a form, chances are that you're just changing a field name of its required flag.

No need to pull up the full field editor with Nenad's new AJAX in-line editing. And a good chance for Nenad to master calling content object methods from jQuery's AJAX handlers.

HTML5 Validation

HTML5 is on its way, and includes some super new browser-based field input validation. jQuery Tools' latest version has some very nice code that retrofits many of these capabilities into earlier browsers. HTML5 browsers will use their native capabilities; old and crusty browsers will get a quick upgrade via JQT. Nenad's been fitting it into PFG so that PFG sends the new HTML5 field validation attributes, along with the JQT support for older browsers. So, you get validation without the round trip to the server, in a web-standards way.

The two most obvious cosmetic changes to Plone 4 are its clean and modern theme, Sunburst, and the addition of popup forms for AJAX modal dialog functions like login, contact form, user addition and history views. (This is, of course, literally the surface of the great new feature set for Plone 4. See the roadmap for a quick view of the change set.)

Behind the slick popup overlays is a gem of JavaScript programming, the ultra-lightweight jQuery Tools UI library from the same folks who created FlowPlayer. jQuery Tools takes care of overlays and tabs in Plone 4, and we've also included in Plone 4 the tools' tooltip and scrollable libraries. And, there's some Plone-specific code that allows us to turn a form page into an AJAX overlay with just a few lines of JavaScript. This is built into Plone 4, and may be added to Plone 3 by installing the plone.app.jquerytools package.

The key jQuery Tools components will add an amazingly small 4kb of weight to the basic Plone page download. For logged in users, the average page size will sometimes be smaller than before, since we took advantage of the overlay facility to separate out page history into an AJAX popup. (For which, we also got an impressive improvement in page rendering speed. The rememberance of things past turns out to be computationally expensive.)

Despite the small size and general coolness of jQuery Tools, its addition to the base Plone package was an occasion for serious consideration and some debate. First of all, no third-party library is added to Plone's dependencies without some serious examination. Second, we know that many Plone developers have their own choices for JavaScript UI libraries, and the Framework Team didn't want to pick sides without good reason. But, we were also aware that if there wasn't any leadership on this, we'd soon end up with multiple UI libraries in commonly used add ons.

Tools, Not Policy

Candidates for our UI kit had to be jQuery-based. And, it helped that jQuery Tools is tiny (around 12kb minified and under 4kb gzipped). The small size isn't just great coding (though the code quality is excellent). It's the result of intentional minimalism. jQuery Tools isn't a framework, and it doesn't carry a design philosophy beyond being CSS-centric. For our purposes, that was great. Plone has its own user-experience philosophy and well-thought-out CSS structure. We didn't want a JS/UI kit that we'd have to code around or to which we'd have to adapt.

Why not jQuery UI?

The jQuery Project's jQuery UI library is an obvious point for comparison. I discovered at the recent jQuery Conference that many jQuery fans don't distinguish between jQuery UI and jQuery; in their minds, they are one and the same, and they don't understand why anyone would pick jQuery, but not jQuery UI.

jQuery UI is a very credible candidate if you're starting from scratch and willing to take its UI design philosophy for your own. Employing jQuery UI pretty much means that you'll be starting with its CSS theme kit as the basis of your style. Or, you'll have a lot of CSS bloat to support your jQUI visual components.

Also, JavaScript's support for object-oriented development is shaky. It's great for light-weight objects coordinated with an event-messaging system, but if you try to design like you're using class-based inheritance, you end up with big objects (code-wise). And, when you add functionality, they have to get bigger, as there's no multiple inheritance and no component architecture. jQuery UI (very much unlike jQuery) is built with this kind of structure. That's not necessarily a problem if your theming is built around jQuery UI, but I can't help but be reminded of where we ended up with Archetypes. It works, but you've got to buy into way too much to get going. Buying into way too much, in this case, means buying into a lot of CSS and JS overhead. Probably ten times as much to achieve just the basics.

And then, since the widget design philosophy is very different from that of HTML5, we might just be ripping out a lot of it not that far into the future....

Your code may be open-source, but what about your project?

Is your software project’s Benevolent Dictator For Life really benevolent?

“Yes” is a fine answer.

“It doesn’t matter that much” is a better answer.

Many open-source software projects have a BDFL, typically one of the project founders. In a healthy project, that authority is nearly exclusively moral authority. There is little or no real legal or contractual authority resting with the title holder.

Moral authority is important. It allows the BDFL to resolve disputes, and a healthy project needs one or more persons with that kind of authority. What’s vital is that the authority can be challenged, and, if not exercised on behalf of the community, lost. The fact that moral authority can be lost is the best insurance it will be well-used.

Most commerce operates under a different model of authority, usually the legal rights of ownership. Ownership of land, improvements, copyrights, patents and trademarks. That is proprietary authority.

Open-source software code is defined by the license. The code is GPL, or it’s not; it’s BSD/MIT/X-Windows or it’s not. Odds are that if you’ve invested a lot of time in working on a body of open-source code, you've made an effort to check out the license. You know what it is, and you've given some thought to the strengths and limitations of that license.

That covers the code, but what about the project that fosters the code? What about the basis of authority in that project?

For code, it’s the license. For the project, it’s the trademarks and the copyrights. Someone — some person or legal entity — owns the trademarks for the project name. Some person or entity owns the registrations for the domain name. And, the person or entity that owns the copyright on the code has control over the future licensing of the code. The value of trademarks potentially dwarf the value of the code.

A concrete example: last year the Plone Foundation did a valuation of the code that makes up the Plone Content Management System. A reasonably defensible valuation, using the kind of methods that accountants use every day, arrived at roughly three million USD. That’s basically an estimate of how much you’d need to pay to reproduce the code base.

If you’ve any familiarity with the Plone project, it’s probably obvious to you that the project as an economic enterprise is worth more. A lot more. Hundreds of times more. Smart people and companies world-wide make a living selling solutions marketed under the Plone brand.

I’ll bet that the same thing is true of your open-source project.

So, you did due-diligence on code licensing. Did you spend some time investigating how the project’s intellectual property is held?

Take a moment. Do a search to determine ownership of your project’s trademarks and copyrights. Do a whois on the domain names associated with the project.

Ideally, you’ll find that the founders of your project transferred the trademarks and copyrights to a well-organized, transparently managed, public-benefit foundation. BDFLs like Guido van Rossum (Python), Larry Wall (Perl), and Alex Limi and Alan Runyan (Plone) earned their “benevolent” titles with great code, good leadership, and by irrevocably conveying key intellectual property rights to foundations that limited their authority. Their authority in their projects is largely moral. BDFL in these cases translates to “dictator for life — so long as benevolent.”

If that’s not what you find, it’s time to start asking questions. Is the authority of your BDFL proprietary? You may trust your BDFL, but do you trust all his or her business associates and heirs? Do you trust that your BDFL will never come under personal, financial or legal pressure that might change their commitments? Are you willing to stake your livelihood on it? Is BDFL translating to “Dictator for life — benevolent or not?”

If you’re like me, the open-source project you work with is the center of a big investment of your business time and energy. If your ability to market and explain your work is based on a trademark license that is “revocable at any time, and subject to changes in policy” by your BDFL, it’s time to start pushing for some better answers. You may be too dependent on the benevolence of a BDFL, and while the code you work on may be open-source, the project might not meet the same test.

Starting with Plone 4.0b3, we've moved the developer-oriented portions of basic Plone setup into a separate buildout configuration file.

That means that the basic Plone buildout configuration that ships with the Unified and OS X installers (and probably the Windows installer in the future) does not include paster and the ZopeSkel template kit.

Instead, these and many other developer-oriented items are now in a new develop.cfg configuration file that extends the basic buildout. So, you may run:

bin/buildout -c develop.cfg

from the top of your install to get a developer kit.

Since develop.cfg extends the base buildout, any changes you make in your buildout.cfg file will be reflected in the results you get when you use develop.cfg.

In addition to the paster/ZopeSkel tools, the developer configuration includes:

• mr.developer, a tool that automatically checks out source for add ons from a versioning system, then adds them to your development package list.
• testrunner, which provides a command-line option to run test suites.
• omelette, which automatically musters python package sources into parts/omelette for easy find / grep access. (Omelette doesn't work with Windows, and won't be included there.)
• DocFinderTab, which adds a "doc" tab to the ZMI to explore documentation for the current Zope object.
• More to come. As commonly used developer tools migrate to Plone 4, they may be added to the develop.cfg. We'll add those that have proven reliable and useful for content-type and theme developers.
  

In case you're wondering, we made these changes just to keep developers on their toes and find out who reads the README files. Actually, that's a lie. The changes were made to give us a good development kit aimed ad content- and theme-level developers without adding any more complexity to the production-oriented basic buildout configuration.

I used to think that JavaScript was a juvenile delinquent: an unfortunate child raised in a broken home; which is to say, a poorly designed language, worsened by bad implementations. Now I think it’s not half-bad.

Usually, when my opinion changes like this, it’s because I learned some things to convince me I was wrong in the first place: I changed. This time, I think it’s JavaScript that’s changed. Don’t get me wrong, it’s still poorly designed and unevenly implemented. But a programming language isn’t just the design and implementation; it’s the culture that surrounds it: the conventional usage, community standards, and common idioms.

Python has the incomparable advantage of great design and a good culture from the very start. It’s a privileged kid. JavaScript has had to grow a culture to compensate for its deficiencies.

So what’s changed my mind about JavaScript?

First, it’s jQuery. I’ve met people who use JavaScript as a general-purpose programming language, but for most of us, there’s one — and only one — reason to write JavaScript: live manipulation of a web page’s objects. While I can’t say jQuery is elegant, it’s really good at slicing and dicing the DOM and at hiding the implementation differences between browsers. And, it does so with paradigms that are recognizable to those of us who think that lists of objects are always the high-level object of choice. (I.E., our brains were damaged by Lisp.)

Next, it’s the developing consensus that there is a safe, sane subset of the language. Think of it as JavaScript-2. Working with JavaScript-2 is a mental discipline: it means pretending that some of the worst features of the language, like the big global name space, just don’t exist. (Don’t miss JavaScript: The Good Parts by Douglas Crockford) JS-Lint is the coding cornerstone of writing JavaScript-2: integrate it with your programming environment, turn up its sensitivity to paranoid, and run it every time you save a code file.

All is not nirvana for the Pythonista approaching JavaScript-2. There are still some unbridgeable chasms between Python and JavaScript culture. A few cultural differences I noticed repeatedly while chatting with folks at the recent jQuery Conference:

These differences strike me as mostly due to environment rather than language-definition (unlike the Rails culture, which has no excuses). JavaScript is mostly used in an environment where everything’s got to run in 100ms or less on a device which may be very slow and very busy. Those of us who have the luxury of writing server-based code have much more control over our environments. We’d be foolish not to add memory, processors, and even new boxes to help enable the programmer to think about algorithms and maintainability rather than User-Interface thread cycles. Writing JavaScript for the browser reminds me much more, in that sense, of writing assembler for my old 64k, 2.5mHz desktop than of writing code for Plone.

Given it’s bad upbringing and unstable home situation, I’d say that JavaScript is doing OK. At least, I’m giving it another chance.

Plone 4, beta 1, will be out any day now. Get ready to test!

And, when you do, please also test the newest PloneFormGen: version 1.6.0b2, just released, which is compatible with Plone 3.1+ and 4.x.

The bad news is that the new PloneFormGen doesn't have much in the way of new features. The good news is that it was very easy to update PFG to work with both Plone 3 and 4. Everything you need to know to update your Plone add on is well-documented in the Plone Upgrade Guide, thanks to excellent work by Maurits van Rees.

Also updated for Plone 4 are the elements of ScriptableFields.

Thanks to David Glick, Matthew Wilkes and Maurits for assists with the PFG update, most of which was done in Budapest and has been sitting in svn trunk until we got closer to the Plone 4 beta.