You are here: Home Articles Pete and Andy try Plone 4
Navigation
OpenID Log in

 

Pete and Andy try Plone 4

by Martin Aspeli last modified Aug 12, 2009 07:38 AM

A tale from the future of Plone. To avoid any confusion: This article has nothing to do with the actual release now to be called Plone 4. It was written as a thought experiment to see how I'd like Plone to be in the future.

Pete and Andy are two IT consultants, both of them generalists. They know a bit of Java, a bit of HTML and CSS, but not very much Python. They've never used Plone before.

One day, their manager tells them to find a CMS for a customer project. Some quick Googling and a Power Point presentation outlining the possible contenders later, they settle on Plone, because it's slick-looking and seems to do most of what they want out of the box.

They set about getting to know the system, when they are told that the deadline has been moved forwards and they now need to deliver a working system in two weeks. Yikes!

The clients' requirements are of course highly confidential, but basically they want:

  • A custom-branded public website
  • A custom-branded editing environment where their staff can make updates to web pages, publish news and events and maintain the site structure
  • Some forms for capturing some basic information from the public
  • A security model with internal and external users being granted various levels of access and various collaborative tools, depending on their roles
  • Some custom content types, with custom workflow, to capture project-specific information and share it among relevant users

Of course, this is all a piece of cake with Plone 4. Armed with a good book, the #plone chatroom and a development laptop each, they get going.

Day 1 - setting up a development environment

Following the official Plone documentation, Pete and Andy download an installer for Plone 4. They pick a Developer's Version that includes some development tools and "kickstart" templates. Perfect!

The installer creates them a buildout. The buildout configures the Paste system to orchestrate a web server for running Zope and Plone using  the Repoze set of components. It also has options for building the Varnish cache server and CacheFu, it's Plone counterpart, for enabling Deliverance and for creating all kinds of interesting pipelines with WSGI. Not knowing what any of that's for, they just leave the configuration alone and go with a vanilla, stand-alone Plone instance.

Luckily, they already have a Subversion server, so they check the buildout into that. Now they can both share the development environment and work in parallel.

The rest of the day is spent on trial-and-error, getting to know how to start and stop the server, where the data is stored (in the mysterious Data.fs file) and so on. They also read up on a lot of documentation - including a short tutorial called "So I Installed Plone - Now What?" - and bookmark the tutorials that touch on the things they know they will need to do later.

Day 2 - setting up the initial information architecture and security model

With Plone feeling a little more familiar, it's time to configure the site using the options Plone provides through its GUI. Working independently, Pete and Andy setup up a rough folder structure to reflect the client's information architecture requirements, create some Collections to collate content in the right places, pick a workflow that fits their review-and-control needs and create users and groups with local rights over different parts of the site, using the Sharing tab in Plone.

Towards the end of the day, they need to merge what they've done and show it to their manager. This is a bit tricky, since they each have a local Plone site - for which they didn't even pick the same name - and they have some overlapping changes.

Consulting the documentation, they realise that they should use Generic Setup to export a profile of their settings. Using the Big Blue Button in Plone's Configuration Management control panel, they each dump a profile to the filesystem. With some manual work, they can merge their profiles and quickly check it into their code repository.

However, Pete thinks it'll be a pain to export-and-synch settings each time they make changes, and so he looks at a tutorial helpfully named "Manging Configuration in Development Projects". This advises him to run a simple command (using one of the tools that came with the developer's installation of Plone, called paster create) that generates a skeleton "policy" package, which he then adds to buildout. Replacing the example profile that comes with this package with the export created by the Big Blue Button, he is able to replicate the settings simply by installing the policy package using Plone's installation control panel.

The next time he or Andy make a change they want to keep, they use the Little Blue Button (next to the big one) in the Plone control panel to export the configuration differences to the correct file inside the policy product, which the Configuration Management control panel lets them select. They now have a way to synchronise settings made through the web with settings made on the filesystem - perhaps obtained via a Subversion update that incorporates changes made by the other developer.

Day 3 - applying an HTML template for public branding

With the basic infrastructure in place and the site configured well enough for a first demo, Pete and Andy turn to the external look of the site. Plone looks good and all, but it's not the aesthetic the client wants. A web designer has already provided them a basic HTML template, plus some mock-ups of a few key pages in the site.

Consulting a tutorial called "Branding Plone", they decide to enable Deliverance in their development buildout. This gives them a directory called templates where they stick the HTML template, style sheets and images from the web designer. There is also a blank file called overrides.css where they can override aspects of Plone's own CSS.

The default Deliverance rules file shows how to wrap Deliverance around Plone with a basic template that replaces the logo and colour scheme and shows how to pull in the navigation tree, tabs and breadcrumbs. Taking this as an example, they quickly get a rough layout where page titles, body content and navigation elements are pushed from Plone into the template.

Andy decides to continue to tweak the CSS and HTML layout. Using an option in Plone's Theme Management control panel, he switches off the "public" stylesheets from vanilla Plone so that they do not interfere with the new theme. He also ticks the box that means logged-in users see a standard Plone GUI, devoid of any theme. This allows him to concentrate on the public theme for now. Later, he plans to generalise the theme so that it can handle Plone's editing environment as well.

Meanwhile, Pete is learning how to use Plone's Layout Page content type. With this, he can create front pages for the various sections of the website that adhere to the mockups the designer has provided. These include static text as well as dynamic listings, managed in the same way as the Collections he has already been setting up. With a bit of CSS added to the overrides.css file in the Deliverance theme, this looks good enough for now.

Day 4 - adapting the HTML template to brand the editing environment

The next day is spending tweaking the theme and layout. Pete and Andy feel they are close enough to a final "static content" management system that they arrange a workshop with the client to get feedback. The web designer has some suggestions for improvements. He is amazed when Pete shows him the Deliverance theme and tells him to make the changes to the HTML and CSS as he pleases. Pete keeps an eye on the rules file so that it all continues to work.

Meanwhile, Andy has completed an alternative Deliverance rules file that applies to logged-in users. He is able to use the same basic HTML template and leaves Plone's authoring CSS intact, but also registers a new style sheet to provide a few specific overrides. Using the Conditional Theming  options inside the Theme Management control panel, he enables this new theme for logged-in users. Other options include having different themes for different areas of the site or for different groups of users. Behind the scenes, this is all managed with clever WSGI pipelines, but what does he care. So far, he hasn't even had to restart Zope since he first enabled Deliverance.

Day 5 - setting up production and testing environments

The client is now excited about the project and wants to let a few of their staff try out the new site. Consulting the tutorial called "Setting up a Server for Plone", Pete begins by checking the buildout and profile out on the server. This time, he invokes the build with two additional options: mod_wsgi deployment and caching support. They also copy a Data.fs file with some example content to the server and install their policy profile using Plone's Configuration Management control panel.

The tutorial shows Pete how to modify the server's Apache configuration to enable mod_wsgi and point it at the Plone site, all thanks to the magic of Repoze. An appropriate example configuration has been generated by buildout, and he is able to paste it in with little modification. He also look at the paste configuration to ensure that virtual hosting is enabled, and sets up the appropriate RewriteRules in Apache.

Meanwhile, Andy has read up on caching reverse proxies. Buildout has already downloaded, compiled and configured Varnish, so all he needs to do is to start it. He then goes into Plone's Hosting Management control panel. From here, he enables a default caching policy that is recommended for standard Plone and most third-party content types. There are many more options to tweak, but it all seems to work well so he leaves it alone. Like most of the Plone GUI, this control panel has contextual help that provides useful hints and explanations. Andy feels confident that he can understand the remaining options if it turns out that he'll need to. For now, he sends the client the link to the site, makes sure it's up and running and head down to the pub. It's Friday!

Day 6 - customizing visual aspects of the site

On Monday morning, Pete and Andy notice a few emails from the client. They are excited by the new site, but as expected they have a long shopping list of things they'd like to change.

Most of the changes are simple and can be managed through the Deliverance theme or simple settings in Plone's control panel. However, a few deeper changes are more tricky. Consulting a tutorial called "Cusomising Plone's Visual Elements", they install an add-on product called Plone Introspector. This came with the Plone Development Version installer, but they have not needed it until now.

The introspector adds a link on every page that takes them to a screen full of information about what they're looking at. They quickly realise how to hide and move viewlets to make the UI a little more logical. They then click the customize button next to a viewlet and edit its template through-the-web. For this, they need to understand Zope Page Templates syntax, but the online documentation makes this pretty straightforward. They continue this process, customising a few images, viewlets, portlets as well as a couple of full-page views.

Pete asks himself where all of these templates are being stored. Following a tutorial, he types http://localhost:8080/plone/manage into his browser. Yikes! That's some scary-looking stuff. After a brief poke around, he sees how Plone's site structure is exposed and finds the container where the customised templates as stored. Satisfied, he closes the browser window and hopes never to have to go back there again.

At the end of the day, the developers return to the Configuration Management control panel and clicks the Little Blue Button. Their settings synchronise to the filesystem profile. This time, however, they are asked a new question - save customised resources? The contextual help makes it clear what this means. So far, their customisations have stayed in the ZODB, but as they know this is hard to manage across environments. By picking the package housing the policy profile, they can write the ZPT files, images and other resources down to the filesystem. These end up in a nicely managed directory structure, thanks to z3c.jbot.

Pete decides to make a few more changes to some of the templates. Instead of going through the Plone Introspector, he simply makes the changes on the filesystem. They are reflected immediately, no restart or re-installation required. He also deletes a few customisations that turned out to be unnecessary.

Day 7 - creating a form

With the client's initial comments taken care of, it's time to move on to some more advanced functionality - forms! There doesn't seem to be any way to create custom forms from standard Plone, so Andy looks in Plone's Add-ons control panel. This gives him some instructions and warnings about third-party components. There is also a list of "recommended" add-ons.

One of them is called Plone Form Generator. He clicks the Download & Install button. A few minutes later, he is asked to restart Plone for the new functionality to become available. He clicks the Restart button and waits a few seconds for Plone to come back.

Immediately, he notices a new Form content type that is available to administrators. Adding a form, he is able to create a set of fields and buttons. For now, he chooses to save all form responses inside the form object itself, and publishes the form so that Pete can test it.

The form content type comes with lots of other options too - emailing responses to a specified email address, allowing users to see each other's responses, enabling tools to analyse responses in aggregate. Pete and Andy experiment with different settings and different forms. They also test the form data export functionality that enables the user to get results out to Excel, XML or SQL.

Day 8 - creating a new content type

The client now expresses a need for a new content type to capture information specific to their use cases. Pete and Andy are unsure how to do this, so they look at a tutorial called "Getting Started with Custom Content Types".

The first step is to run another paster create command, this time to create a content type product. Following the on-screen instructions, they give their package a name, choose a name and some basic properties for the content type, and install it into their buildout. Looking at the results, they see a couple of lines of Python and an XML file. The Python (in a file called staffdirectoryentry.py) looks like this:

from plone.app.dexterity import api as dexterity

class IStaffDirectoryEntry(dexterity.Schema):
    pass

class StaffDirectoryEntry(dexterity.NonFolderishContent):
    pass

There is also a configure.zcml file that contains this:

<configure xmlns="http://namespaces.zope.org/zope"
  xmlns:plone="http://namespaces.plone.org/plone">

  <plone:contentType
    schema=".staffdirectoryentry.IStaffDirectoryEntry"
    class=".staffdirectoryentry.StaffDirectoryEntry"
    configuration="staffdirectoryentry.xml"
    />
</configure>

The tutorial explains that this gives them a fully-fledged content type, with an interface/schema that can be used by other components. The type is managed by an XML file, which contains basic type information (name, where it is addable, whether comments are enabled and so on), a schema (a series of fields with associated options) and the definition of an edit form and a view.

Rather than editing the configuration file directly, Pete and Andy start up Plone and go to the Content Types Management control panel. They pick their new content type package from a list and are taken to a screen where then edit all the basic content type properties. They can also create, edit, re-arrange and delete fields in the schema and manage views through-the-web. At the end, all of this is written down to the same XML file, ensuring that their settings will be retained even if Zope is restarted.

Along the way, Pete tests the content type with input from the client, who is on-site for the day. Making changes to the schema and seeing the results is quick and easy. It's all done though the web, no restarts required.

Towards the end of the day, Andy stumbles upon a tool called Genesis. This is able to take a UML model and turn it into a content type, by generating the same type of XML file they have been using already. He installs it, and to his surprise discovers that it is able to read the file for the content type he's been working on. Making a few changes to test this different UI, he saves the XML file and returns to Plone to reload the content type. As expected, the changes take effect immediately. Andy makes a mental note to use Genesis if more complex needs arise later, since he prefers the model-driven user interface. Pete is less sure, but agrees that getting a quick UML representation of the content types is very useful.

Day 9 - adding additional behaviour to content objects

The client is happy with the new content type, but requests a few changes. They want a custom vocabulary with some customised logic, they want an email to be sent when a certain field exceeds a certain value, and they want the navigation tree to behave a little differently for the new content type.

This is a challenge, since none of these things can be achieved through the web GUI. Pete and Andy put on their developer hats, keep their Python and Plone books close to hand, and play around with the Plone Introspector in order to discover the APIs supported by various objects they see in Plone. A tutorial called "Advanced Content Type Programming" provides them with plenty of good examples, too.

Pete quickly realises why the content type package had a class and an interface in Python. These serve as "hooks" for components that they now register - a utility for the new vocabulary, an event handler for the email functionality, an adapter for the navigation tree customisation. Using examples and suggestions provided by the friendly people in the Plone chatroom and liberal copy-and-paste programming, they manage to write get this functionality working. They even write a few unit tests, using the test skeleton provided in the content type package.

During development, they use the package refresh functionality in Plone's control panel for changes to take effect. This provides helpful error messages when they get the syntax or logic wrong, and attempts to isolate the package so that a bad change doesn't take down all of Plone. Restarts are quick enough when they are required.

Day 10 - deploying a static copy of the initial site

While Pete and Andy have been polishing off the functionality, the client have busily added content to the testing instance. For the time being, they do not want to use the production Plone instance directly, since their IT people are a bit nervous about taking over a new application server. Instead, they'd like to just host a static copy of the anonymous web site. They have a server with Apache and PHP that they'd like to use.

Andy goes to Plone's Deployment control panel. There he finds a Big Green Button. He pushes it and covers his eyes. A minute later, a bunch of static HTML files appear in a directory on the server, covering the Plone site, with basic navigation and a site map. Search is provided via a form that posts to Google for search results on the current site.

However, the static site is using the standard Plone skin. Andy returns to the Deployment control panel and changes a few options - he chooses the public theme from a list of known themes, and ticks the PHP output option. This gives much the same look-and-feel, but as a bonus it has a better integrated search function and portlets such as the RSS portlet continue to work. Nice!

Behind the scenes, all of this is managed with a bridging technology called Entransit. Reading up on it, Andy sees that it can support a number of deployment scenarios, including one target platforms such as ASP.NET and SQL-based content stores, although these sometimes requires some custom programming. For now, the basics will do, as the client is likely to use a full-blown Plone-behind-Apache setup for the final deployment. Still, it's nice to have options.

THE END

(now all we need to do is to make this all reality)

Document Actions

I never know what to put into the subject line ;-)

Posted by http://mrtopf.myopenid.com/ at Feb 02, 2008 08:32 PM
Very nice writeup and I agree it sounds possible.

Some notes:

- IMHO viewlets should maybe simply be dragNdroppable.
- if there is a Layout page why not let this layout page also handle viewlets and portlets? Ok, these might be more part of the layout around the page but maybe it should have something similar.
- I would like to see some SQL story here, too ;-) (Pete and Andy might have some legacy data or some influential IT dept which want something known instead of ZODB)
- I do not really like the Entransit part as it always sounds to me like rebuilding the site. Esp. if (and I think this will happen in the future) those sites need to be more and more dynamic. I'd rather like to use Plone technology here as it has all what I need.

And maybe instead of Python and Plone books say "fantastic online documentation" (+ community) ;-)

Mostly agree

Posted by Martin Aspeli at Feb 03, 2008 07:36 AM
I agree about bringing the concepts of viewlet and portlet layout management closer, but it will require a bit more thinking since having them all in one UI is probably not a great idea. Portlets are managed differently (by folder, user, group, content type) and are much more in the "site admin" domain - viewlets are in the "integrator" domain.

I'd like more of a SQL story too. I think there are some simple things we can do, e.g. have a content type where you type in a SQL statement and the results are shown on the view (read-only) in a grid, with paging and basic sorting and searching. Deeper read/write integration will always be more specific since it depends on the underlying database schema. I'm hoping collective.tin will be the most commonly used/promoted bridge here.

I don't understand your dislike of Entransit, though. Having a straightforward way of publishing a static site in the $5/mo web hosting is really important. Not everyone needs a fully dynamic *public* site, they just need Plone's content *management* environment. Entransit (or something similar) gives you a common platform to plug in different transformations and targets. I think we should ship with one or two basic ones. People can then add new ones if they wish, though of course, for people who want the easiest and most dynamic deployments, deploying Plone behind Apache (with Repoze and mod_wsgi, probably) will be the default. It's just about having other "escape routes" that give people confidence that Plone is not a dead-end for their content and that they don't *need* a $200/mo public server to get any value out of Plone.

Martin

About Entransit

Posted by http://rsalves.myopenid.com/ at Feb 03, 2008 11:25 AM
I agree when you say that "having a straightforward way of publishing a static site in the $5/mo web hosting is really important". Yes it is, and technically I consider it very important to have such an option. But IMHO this kind of deployment won't ever be very popular. And, if we include it in the core, we may be giving the wrong message that Plone isn't recommended for production environments.\

Ricardo

static export IS good

Posted by https://deichi.meinguter.name at Feb 04, 2008 04:45 AM
I don't agree on that entirely. Of course it would be better if Zope would be pre-installed on every hosting server! With all its disadvantages that would have for us a hosting provider...
The only problem I have with the PHP export version is, that PHP is the security aspect.
We often have clients that would like to have a static page (because of the performance), but like to edit it off-site with an easy-to-use CMS like plone and automatically sync that with the static version as soon as the changes were approved by the person responsible for the whole site or even by a section specialist followed by the responsible person.

reply

Posted by http://mrtopf.myopenid.com/ at Feb 03, 2008 04:58 PM
Well, having a better SQL story might also mean not having the need for some extra export step. Content already resides in the SQL db and thus only the frontend needs to be written.

And I think this might be some work to write it. I just experiences with Django how it is to have barely nothing what I usually rely on having Plone (no basic template, logic and so on).

But that probably depends very much on the site you want to create.

Still I hope that we don't use Entransit as an excuse for Plone being not that fast and instead try to make it faster ;-) (but I guess that fact is quite clear now to most people in the community).

Regarding SQL I really would like to have some more flexible approach a la ZPatterns. Today I wrote a z3 based content type and might experiment with my ideas a little bit.



Great Article!

Posted by http://rsalves.myopenid.com/ at Feb 03, 2008 11:22 AM
This guys are really good... and they even write some unit tests after a few days :)

About the features you describe for Plone 4, the usage of Deliverance for branding the site looks promising, and the new way to declare content types would be a huge step forward.

I can't resist to add some ideas. Lets say that on day 11 Pete and Andy faced the need for specific search forms in different areas of the site. So Pete reads a tutorial called "Create Custom Search Forms" and learns he only need to configure a Collection, adding criteria (from available types: String, Data Range, Selection, etc) and he can define a specific criterion as "searchable" (can be filled by the user through a search form). Then the collection behaves like usual but presents the user with a form to search/filter results.

Ricardo

Hail to the king! ;)

Posted by https://deichi.meinguter.name at Feb 04, 2008 05:03 AM
Martin, you took the words right out of my mouth. or the one of my boss ;) The scenario you describe is exactly what we do every day. If all that would be possible today, our life would be much easier. And 2 weeks would be great for us too ;)
We usually hit Plones (or our own) limits on several points you mentioned. Plus: a) Plones development is very fast. It's API changes much too fast to keep a living site up to date. we were forced to migrate all living sites to 2.5 already to keep up. But imagine we started only a few years ago and Plone 2.0 was bleeding edge back then. It started to become really good with 2.1 and effectively usable with 2.5
Especially the TTW configuration and its reflection on the filesystem is one of Plones weakest points today.
b) Plone has a vast set of CSS rules already in place that affect many things you would usually like to style. (and uses too many !important ...)
c) Plone tends to become slow very easily (I know thats Zope "doing too much", but on the end it's Plone the customer sees).

And yes: I know that Plone 3 has done much in all those aspects. (But I also know that Plone 3 is still not usable to us, since many of the Products we use are not yet ported to Plone 3)

One additional word to Entransit: It also brings real staging to Plone. Currently no Plone version brings conservation of the _currently published_ version. It is NOT acceptable that someone brings approved content down for the time it is modified in a usual site.
Imagine you take the ArchGenXML tutorial on plone.org down, because you corrected a missing comma somewhere and wait for approval...

Response

Posted by Martin Aspeli at Feb 04, 2008 06:41 AM
Fast development is a blessing and a curse. There is much work to do, we can't just sit on our hands. We'd lose the momentum and people would get frustrated.

I'm not sure Plone's CSS is such a weak point. I've done ocmplex styling, either by turning off public.css and base.css, or with those intact depending on the need. In general I find that pretty easy, at least once you understand the basic principles.

Speed is a separate issue, of course. Often, add-on products are poorly written in terms of performance. Some tweaking is necessary. However, on a modern server with caching enabled, Plone can be pretty quick. There's more work here too, of course. Oh, and 3.0 is faster then 2.5.

Entransit is not really about staging. We have proper staging in Plone 3 - it's called iterate and it ships with Plone, alebeit uninstalled.

Martin

Excellent

Posted by http://mattgow.wordpress.com/ at Feb 05, 2008 11:30 PM
Martin, this is gold (like everything you write).

It's re-invigorating my Plone muscles.

I hadn't heard of collective.tin before the reference in comments here but I'm *extremely* pleased to learn such a thing exists. It would be *huge* to be able to say that storing data in an RDBMS that is potentially updated from other sources is possible with Zope/Plone and we will be investigating this lead asap. Having no possibility for independent SQL storage is a big bridge to burn during the technology evaluation for a project even if Plone/Zope/ZODB has a big % of the requirements covered.

Entransit is also a major win in this direction. I feel that *any* technology that increases the integration capabilities of Plone is a big step forward.

Plone 3 is something to be very proud of and we are enjoying the results we are getting with it.

Please sign us up for the vision of Plone 4 described above. We want to work that way.

so inspirational...but

Posted by http://hamzat.myopenid.com/ at Sep 03, 2008 07:03 AM
I have keen interest in knowing plone as such I ordered your book when it was yet to be published. At that time i was struggling with version 2.5 reading Plone Live (another book) as my guide. The main problem that i have identified as a beginner who does not have the financial power to go for professional training is the speed at which things are changing in the world of plone. I am not in any way against this rapid development but you need know how I feel each time i realise how much I need to know to make something reasonable with this product.

I was in that mood when i came across an article "Is Plone too Hard" and it was inside it that I saw a link to this article. I quickly made up my mind to follow the steps one after the other.

My first point of call was to download plone 4 installer and when I got to the plone 4 download page i could not see any installer to download, I was actually scared to say this because I do not want to look stupid if it is there but i was not careful or be patient enough to see it. This search took me more than 2hours, and i was even forced to search on Google without success. The question that kept coming to my mind was that where did Pete and Andy download their copy?

To me this is another major setback facing the beginners. Reading something and not able to follow it up by practising it.

KH

This is a WOW post Martin!

Posted by http://davidgodin.myopenid.com/ at Feb 18, 2009 02:55 PM
I’m in charge of development projects working with commercial CMS. When I was approached by a none profit organization to build a multilingual, collaborative community site, I evaluated many open source CMSs. Plone was an obvious choice for its mature core features, fully integrated Database engine, small footprint, many add-ons and best of all, the best multilingual integration I’ve seen to date in any CMS.

I think Plone could go a long way by having more User/trough the Web polishing. What you propose for Plone 4 is fully on par with me needs. I understand that Plone’s evolution is driven almost exclusively by developer needs and that being so; many features require “Coding”. Thanks to you Martin, since I’ve bought and read your Plone book I now use Buildout and Paster to work my Plone sites, but I often feel lots of things I’m doing should just be a bit more simple and fluid. 99% of what I spend time on has to do with Site design (template layout, adding Viewlet and Protlet managers, creating very simple Viewlet for specific visual need, working stylesheets and the like.

Here is what I think Pete and Andy would also be dazzled by in Plone 4:
Now they tackle the Site design portion of their project, everyone knows, this can be a tedious task. They have no Python, Zope, ZPT or ZCML knowledge, but hey, unless you want to really write custom functionalities, who should cares about code, right? This is just about layout and styling after all. And so they hit the Theme Management link. In there they see Templates, Visual Gallery and Template Assignment. They take a quickly look at the draft sketch the design firm sent them and hit the Template link. This is where they can create and manage templates in which they visually define a bunch of columns and rows with size and position. Those columns and rows have buttons to insert, delete and configure Plone’s visual elements. Once they are happy with their general layout, Pete and Andy save the empty Layout template (or Layout content type) and give it a name. Who cares if it’s not perfect for now, or if the design firm changes the layout, it’s so easy to change anyway.

They then need to plug in the visual elements so they hit those buttons in the template Layout zones they’ve just defined and are then shown the Viewlet and Portlet Gallery. This Gallery is categorized with Vanilla Viewlet and Portlet objects or saved objects they configured and saved in the past. In the Gallery they find everything they need, from the Search Viewlet, Portal Logo, Language bar, Calendar Portlet, Navigation Portlet, etc, up to the main content Viewlet. They insert what they need in their template defined zones and then save their template using a different name. Who knows, they might reuse this layout for other sections of the site once the designers send them more info. Wow that was fast; they did all of this well under 1 hour without having to look at any files and trying to learn a new language, markup language definition or the location of the relevant Plone files, but most of all without a single line of code was needed!
On top of this they know they will be able to use the Theme - Template Assignment and reuse any template or different ones for different parts of the site as needs.

Now for the styling work, they hit the Big Green Button and choose Site Maquette as the export format. This create a static html version of the site. The Plone help says this Maquette is built using the Plone Stylesheet and that it can be sent to web developers so that they can work the design styling from a Plone ready CSS file and see the results with whatever tools they prefer to use and without Plone running. Hell that’s a time saver, they’ll just need to replace the CSS file with what the designers sends back.

I have nothing against Deliverance but it sounds like a complex variable to the simple equation that is Plone.

Keeping looks separate re logged in and public

Posted by http://emb03.myopenid.com/ at Sep 05, 2011 05:24 PM
In your article you mentioned that you ticked off a box in the theme management so that logged in users see the traditional Plone design and not the custom design. I can't seem to find this control panel. Can you direct me?

Thanks!
Elaine

P.S. I am having a terrible time controlling the logged in view without affecting the public view. Any pointers welcome!
Plone Book
Professional Plone 4 Development

I am the author of a book called Professional Plone Development. You can read more about it here.

About this site

This Plone site is kindly hosted by: 

Six Feet Up