Tactical Agility

As we have been working on some new functionality for BrowserCMS, it dawned on us that we were doing was slightly bigger than bug fixes and integrating community patches. As a result, we have created a branch of BrowserCMS based off the 3.0.4 release and labeled that 3.0-stable. 3.0 will now be maintained as a bug fix branch, primarily aimed at patching up the support for IE 7/8. I expect 3.0.5 to be done shortly.

Goals for 3.1

There a few highlights goals for what we want to get into 3.1, some complete, some in progress and others just on the wishlist. Here’s a quick overview along with [Status] of the work.

1. Upgrade the default WYWIWYG editor – BrowserCMS comes bundled with FCKEditor, and there is new version out CKEditor which is a pretty nice upgrade.  Getting a cross browser compatible spell check alone is probably worth the price of admission. There is a ‘but’ however, because CKEditor doesn’t come with an open source way to browse the CMS file repo for linking. [Done]
2. Create an FCKEditor module – This will allow developers who want to continue to use FCKeditor, for either file linking or just avoid confusing their clients. [Planned but Not Started]
3. Create a commercial CKFinder module – CKFinder is the commercial file manager designed to plug in to CKEditor. We want to explore creating a Commercial BrowserCMS module that would allow CKFinder to be used as the file browser. [Not Started]
4. Acts As Content Page – Developers should be able to create controllers that can more easily take advantage of the CMS core services, like Authentication, Authorization, Templates and error handling. This feature is a first pass, and I have few ideas on to refine this in further versions. [Done]
5. Portlet Workflow Improvements – Portlets make it easy to allow their views to be editable via the CMS UI. The challenge was that by default it was hard to refine the initial render.html.erb unless you removed the template editor controls. This features creates a new Form Helper for rendering the template editor, which is disabled by default. This lets developers easily get the portlet view how they like it and then turn on the editor with a single boolean. [Done]
6. Documentation - One of the biggest roadblocks standing in the way of productive BrowserCMS developers is the state of documentation. As part of 3.1, we are planning on focusing on improving the topical guides around the things developers touch the most, namely Blocks, Portlets and Templates. This article from some of the Django folks on Writing Great Documentation contains some good guidelines for what we want. [Not Started]
7. Command for creating BrowserCMS projects – Right now the command for creating a new project is both fairly long since it needs an application template path, and it also has an external dependency on where that template is. This makes it complicated to release new versions of the template. Ideally, we it should just be possible to type ‘browsercms project_name’ to get your project. [Not Started]

That’s probably about all I suspect we will aim for in 3.1, but hopefully this should give a better sense of where we are trying to go with the project. I’m also going to try to draw up some broader goals for 3.2 and beyond.

Let me know your thoughts either here or in the project Mailing List.