Zope 3 and CMF

* Z3 learns from CMF

There have been tiny releases to fix little issues. The release we talk about today is a bigger leap. Zope 3 also has some techniques that are good and done in a better way than in CMF. Seperating the concerns was one goal site designers, content authors and developers should not interfere too much. Policies should be pluggable. Seperate from the class that implements a type a type should be a level of abstraction you can attach policies to. Z3 uses the concept of the interface as a basis for doing policies. Plone was originally just a skin for the CMF. Now plone ic much more.

At the python conference 2004 people working on Plone, CPS and Silva realised that a lot of people would need the same developments and people started to identify the lack of collaboration as a gap we have to come over. Then there was a try to get all people into the same room to find out how to achieve this and to track down the requirements.

Castle Sprint last year: Martijn said one of the things in the way is that nobody wants to use Zope 3 because Zope2 is still there in a lot of production systems and he has FIVE and you can use it right away. Five is a good way to play with Zope 3 you can nibble of bits and bytes of Zope 3 and still pay your bils with Zope 2 ;-)

Collaborations started.
Zope 3 Enterprise Content Management Project
If you don't know what committed bandwith is you are wrong in Enterprise Content Management. Most of what we need could be done witn pure Z3 technology if we needed it.

Goldegg also means using as much of the Z3 architecture as we can. Five as it stands today does not know about local policies. There will probably be another version of five or cmf would move forward to help in implementing this. Refactor plone skins to make them work. CMF 2.0 requires Zope 2.8.1+ and Five 1.1+. How do you let an external Service know that there was a change in content? Architecture for import and export of content.

Time Frame
Goldegg is already going on. Castle Sprint after the conference will have more than one trail. In October there is a sprint in San Jose. Perhaps in November CMF 2.0a1 is going to be out. We try to stay with stable Zope releases not with unstable.

Skins in any site get more and more complicated, because you add logic. It is easy to put logic in the skins. If you look at the subversion or cvs diffs you will find a lot of things that should not be in templates. If you keep it in two places you might break the python and and unfortunately also or the template. Some things need to be tested through the browser port but most things don't have to be.

Q: Another reason for logic in the templates is the fact that you can do that through the web.
A: You loose track of the state of the software with that kond of customisation. But the usecase is important. Zope 3 does not even have the idea of doing that.

Jim Fulton: In Z3 and therefore in Z2 there will be the ability to work on template through the web and a process that would turn them into filesystem based products when you are finished, but it will some people who volunteer on working on that.

Q: Can you give an example of a view logic?
A: I don't have an example of a complicated plone template versus a simple one. Mike Peletier simplifies templates at the moment.

Q: Martijn: Mike does something similar on the templates but noe exactly the same.

It is also a performance gain. The simpler the template the faster it might get. When you use CMFDocument you can put html inside or structured text and the body gets cooked on access. We might keep a stored version of the output to speed up the page. Some of the html should be 'scrubbed off'

Events
The content object has to tell the framework about a lot of stuff. "Hey workflow! I am new!" The only job is to tell the framework about the event, not knowing what component would handle the event. The code will be subscribed with those events. Otherwise you screw up the security or you might get wrong. Kinds of events: 'Content', 'Container', 'Workflow', 'Timing'

Subscribers
Deferred indexing. Application errors shoudl rollback the transaction. Cataloguing shoud be deferred to the end of a transaction, usually objects are modified a couple of tiumes, and averytime it needs to be catalogued, because we have to make sure the call happens. This should be deferred.

Content Import Export
Stage content between instances has been an important usecase. If you have a relational database. Nobody expects that an update will just work. Dumped ZODBs and upgraded Software would not work right away.
No 'Lock-in' on content.

Adapter based serialization.
zipfile as export format, filesystem, parallel folder structure.

Performance hack to get your skins out onto the file system

skinfreezer_tool!

it is shadowing multiple paths and is faster than objects in the zodb, because it is on the file system. You can pick among a list of scripts and give a product name, class name and then save. [...Tres selects all...] Now a 'save as' dialog comes up. A __init__.py is being generated, containing all the scripts, turns them into methods and python classes. In zmi you can now add the 'freezer thing'. in portal_:skins you create a new skin with all skin layers. There is no image or file support bult in until now. [...Tres creates a skin called 'alternative'...] Then he runs a performance test witn ApacheBench (ab), it is 44 request per second.

Questions?

[...Paul is saying than you to people involved...]

Working better with the Plone People is a real goal, Geoff Davis and Whit have done a lot regarding this in the recent time.