Plone
This is here to serve as contents for the atom/rss feed for Plone, also read by planet.plone.org.
Content rules
Plone conference 2007, Naples. Speaker: Kamon Aveya Company: Ingeniweb
Plone conference 2007, Naples. Speaker: Kamon Aveya Company: Ingeniweb
In Plone Content is king. Content is a first class citizen. You manage content. But we still do a lot of stuff manually: content modification, reviewing, publishing, awareness of content/workflow changes, collaboration, etc. Of course you can add python code to do some things automatically.
"Content rules" to the rescue! This is a new feature in Plone 3. It allows the Manager of the site to automatically do things with content.
We have a content rules engine. Rules allow automatic actions based on triggers. Rules consist of three parts: if an event happens and if a condition is True, some action is taken.
The main events that are available to the rules engine are: an object is added to a container (folder), or removed from it, or moved to another container, an object is modified, or its workflow state has changed.
Possible use cases:
- Moving contents automatically.
- Log content modifications in the event log or somewhere else.
- Provide notifications as a status message.
- Send email messages.
You get these use cases out of the box with Plone 3. They work already. So some of the things that you were doing manually or by writing some custom code yourself are now available by default.
What you can do, is manage News items better. You can put News items anywhere. You can have a Collection for having a central folder that shows all News items. But having News items all over the site is not very nice. So you can use a content rule: when a News item is published, it is moved to a specific central folder.
In the Content rules configlet in the Plone Control Panel you add a new rule with the workflow change trigger. You select some conditions then: do this for the content type News item and only for the publish transition. And you select an action: move it to a folder of your choosing.
Now you go to the root of your site and as Manager you click the Rules Tab. At that point you can say which content rule you want to use here and in sub folders if the rule is not activated globally.
You can add an email action. That has a field where you can use things like ${title} and ${url}.
Other examples:
Track the removal of content. This works already.
Prepopulate a folder, for example a MemberFolder. You can write an action for that. The start of an implementation would be:
class IPopulateAction(Interface): skeleton_folder = schema.Choice(...)
It is powerful and extensible. Use it when it makes sense for your use case!
plone.portlets
Plone conference 2007, Naples. Speaker: Geir Baekholt
Plone conference 2007, Naples. Speaker: Geir Baekholt
The left_slots and right-slots properties are probably the oldest piece of Plone that is sill in 2.5. It is at least seven years old. It is not working really nice for users or developers.
Then we had PlonePortlets. With this product, portlets became content objects (which is not terribly nice). They worked but has many side effects.
In April 2006 we had the Archipelagosprint in which we spent time thinking about portlets and coding a bit. Then everyone went home and did nothing about it. Except Martin Aspeli (optilude on irc). He almost singlehandedly (well, with help by Philipp von Weitershausen) coded plone.portlets and plone.app.portlets which is in Plone 3.0.
In Plone 3.0 portlets are objects, not templates (although there are templates in the background of course, to actually show the portlets in the browser).
Default portlets are the login portlet, navigation, calendar, recent items, news, events, search, RSS feed (though it does not work), review list and the classic portlet (which we will see later).
Adding portlets is now more involved than just setting the left_slots and right_slots properties. They can be assigned to context, users/groups and content types.
With the Manage Portal permission you have a link at the bottom of the left and right slots to a page for managing the portlets of that context. You can also block portlets in subfolders. Due to a bug this does not work in Plone 3.0, but it does work in 3.0.1.
Often you want to have a portlet that is only visible to for example the finance department. You can now do this in the Group Management in the Plone Control Panel. Go to the Group Portlets tab and add left and right portlets there for this group.
You can have user portlets. A user can add portlets in his personal dashboard. Click on the user name (next to logout usually). Edit your dashboard there and add your favorite portlets.
There is a static portlet in the collective. It is a good example that you can copy. Also look at the Collection portlet, which can come in place of the News and Recent Items portlets.
These new portlets are a bit more complex than the old ones. For backwards compatibility there is the Classic portlet so you can still use them (with all its downsides of course).
Portlets are not viewlets. Portlets are persistent. Viewlets are defined in zcml.
Porlets have at least: interface, assignment, renderer. Possibly also an add form, edit form. Interface describes what it looks like (it has a header attribute in our case), inheriting from IPortletDataProvider. The Assignment class implements that Interface. The Renderer class renders the portlet (mostly using a template). It also has a method available so you can use that to conditionnally show the portlet. You wrap all this up with some lines in a zcml file.
In the future we want to have more GenericSetup support for this so you can define portlet assignments in xml so you do not need to write code for this. (Are there any volunteers?) We need widgets for more advanced configuration. We need more reusable portlets. Try it! We also may come up with a paster template that you can use as a starting point for your own portlet.
Multimedia in Plone
Plone conference 2007, Naples. Speaker: Nate Aune
Plone conference 2007, Naples. Speaker: Nate Aune
Plone has rss 1.0. This does not support enclosures, so not podcasting. Plone4Artists improves this. It uses Zope 3 technologies: it does not introduce new content types. You can just use it to adapt existing content types.
Plone4ArtistsSite wraps together a few of the Plone4Artists products.
We went from CMFAudio (CMF) via ATAudio (Archetypes) to Plone4Artists (Zope 3). Instead of ATAudio, ATVideo, ATPhoto we just have default content types like ATFile, ATImage, ATLink and adapt it to our needs with Plone4ArtistsAudio/Video, etc.
Example sites: http://talk.bmc.com, http://engagemedia.org, http://thedailyreel.com, http://bilive.it, http://phonogen.com and since last Thursday... http://plone.tv!
Id3 metadata is automatically extracted by Plone4Artists and when you edit them they are written back to the audio file. That is cool.
With WebDav you can upload audio content to Plone.
You can turn a SmartFolder into a podcast.
Uploading large files is tedious in Zope. To improve this you now have ZipFileTransport, PloneFlashUpload and Tramline.
More info: http://plone4artists.org/products
irc: #plone4artists on irc.freenode.net
Introduction to the ZODB
Plone conference 2007, Naples. Speaker: Laurence Rowe
Plone conference 2007, Naples. Speaker: Laurence Rowe
The ZODB stores objects, not rows of data. When dealing with rows like in a relational database and you change the data layout, you do alter table statements for migration. In the ZODB that does not happen so you need to do that differently.
Transactions
Zope 2.8 introduced transactions, which means:
- concurrency control
- atomicity
- less conflict errors
When you do a lot of writes in the ZODB you will encounter conflict errors. Most of them should be resolved automatically. But if this happens a lot, you need to improve your code. In some cases BTrees help, so using BTreeFolders as base for your folders. Also a product like QueueCatalog can help. This defers new calls to the catalog, which can speed things up at the cost of not always seeing up-to-date data.
Sending emails might happen twice if the transaction gets aborted somewhere in between.
Scalability
Python has a Global Interpreter Lock, which means a python process can use just one CPU. Zope can use ZEO to handle this better. One ZEO server serves the data to several ZEO clients. A ZEO client is basically a normal Zope instance but with the database being managed by another process: the ZEO server.
You can also store for example the catalog in a different ZODB. You can tweak the caching of the different ZODBs to fit whatever you put in that particular database. A lot of big sites to this.
Storage types
Almost everyone uses FileStorage. This stores the database in a single file Data.fs. DirectoryStorage can be used in some cases. Newer on the block is PGStorage which stores the data in a PostgreSQL database.
Other features
- Savepoints: you can go back to one state that you know is safe, instead of reverting the complete transaction.
- You can store versions, but that is deprecated.
- Undo, but this is not always possible. If you put for example your catalog in a different storage, you will find that an undo of the main database does not undo the change in that catalog.
- BLOB: large file support (in newer ZODBs).
- Packing: remove old versions of obejcts. Similar to doing a vacuum in PostgreSQL to reclaim used space. It gets rid of undo information.
Best practices
- Do not write on read. If your object for example uses setDefault, you may find that the first time you read that object it actually gets written.
- Keep your code on the file system, not in the ZODB, like the custom folder. That quickly becomes unmanageable.
- Use more BTrees. This scales better than normal trees. BTrees handles thousands of objects more efficiently CPU-wise and memory-wise.
- Make simple content types. Use adapters if you need more complexity on top of the base content types.
Documentation: http://wiki.zope.org/ZODB/Documentation It is a bit old though, more about earlier versions of the ZODB. But still a good source of information.
Why you should learn more about workflow in Plone
Plone conference 2007, Napels. Speaker: Vincenzo Di Somma Company: RefLab
Plone conference 2007, Naples. Speaker: Vincenzo Di Somma Company: RefLab
Workflow from the beginning. This is mostly a hands-on talk, showing the portal_workflow in the ZMI.
Workflow is basically: during the life cycle of content there are changes in who is allowed to do what.
In Plone we use the workflow to manage the publication process. But we can use it for other things.
Plone 3.0 by default has six workflows now that you can choose from.
About four people in the audience have created workflows in the ZMI. About three have used ArchGenXML for this.
In the ZMI you can manage workflow variables. Usually: action, actor, comments, review_history, time. But you can add more yourself.
You can add worklists. By default there is the reviewer_queue. This is used by the Recent Items portlet to get a list of items that are in the pending workflow state.
On the Permissions tab you can list permissions that should be handled by this workflow: who is allowed to do what in which state.
Files and Images have no workflow anymore in Plone 3.0 by default. Question from the audience: why do they not have a on-state workflow? Answer: there are differences, but I would have to look up the code. Probably there are differences in what Anonymous visitors are allowed to see.
There is also the CMFPlacefulWorkflow, which you can install with the quick installer. [About three in the audience have worked with that.] It is very powerful. It lets you specify workflow policies. In there you can set a different default workflow and assign different workflows to content types. Within a folder object you can specify which policy to use. So you can use a different policy in different parts of your site.
You can change workflows through the ZMI or with a python file or with the newer, better way: with a xml file in a GenericSetup profile. In portal_setup you can export your current workflow to an xml file, because you do not want to create such an xml file from scratch.
Use case: Smanettona. Site for learning children about computers. Content that is added should be checked by an adult first. We use default Plone publishing workflow for the corporate part of the site. We use a restricted workflow for the home folder of the users. And an even more restricted workflow for the magazine.
You can manage more than just the publication process. You can send emails when a transition occurs. You can have worklists, like the reviewer queue.
Common requested improvements by customers on top of workflows:
- email alerts on workflow change (look at content rules in Plone 3.0)
- explicit selection of actors (like reviewers) by group, sections, etc.
- multireview: transition needs to be done by more than one person.
- link transitions: publishing A also automatically publishes B.
- multi site life cycle: once content is published on site A it is automatically published on site B.