Zope

on the Plone 3 for Education book by Erik Rose, here are my final impressions. I will cover the whole book now. To make it very practical, for each chapter I will recommend which of my at Zest Software should read it. For some it will just be a ... [More] reminder of what they already know, but freshening up your knowledge and perhaps picking up some small tips on the go are always good. Note that some have multiple roles, so someone may be listed first as trainer and later as programmer. This is about creative application of the default Plone content types. It explains how to use some features of standard Plone, like collections, large folders and default pages. Recommended for Esther (Partner), Robin (Marketing/Sales), and Angela (Management Assistant). The Plone4ArtistsCalendar product is used as a nice way of showing events; this looks like a good solution for sites with lots of events. The chapter teaches best practices for using events and collections. You also get some tips about how best to apply security and permissions. Recommended for Esther (Partner), Robin (Marketing/Sales), and perhaps Mirella (Project Manager), mostly because they may be doing content management on some client sites or on our own site. The add-on product Faculty/Staff Directory can be seen as a departmental website in a box. It uses membrane, remember and relations. It is a versatile product, which could be useful in several occasions. Recommended for Jean-Paul (Partner) and Robin (Marketing/Sales): they should know this product is available; also recommended for the programmers (Mark, Fred, Vincent, me): they should see if this product fits the bill, before making something from scratch. It can also serve as a good example of how to use the membrane and remember products. The standard product shown in the previous chapter is now extended using archetypes.schemaextender. Recommended for Mark, Fred and Vincent (programmers): look at this to freshen up your knowledge of archetypes.schemaextender (or for your first look at this). This is a look at the out-of-the-box blogging potential of Plone (which may be enough), and at add-on products. Erik calls these "free as in puppies": they are cute, but you should be aware that they come with responsibilities. All add-on products that you may want to add in your site, should first be tested on a copy of that site, including trying to uninstall it. The QuillsEnabled and Scrawl products are introduced for blogging, including using them in combination if needed. For forums the judgement is clear: use Ploneboard. Recommended for Mark as consultant and Fred as consultant/trainer. For embedding audio and video, Erik recommends collective.flowplayer as the most flexible and trouble-free solution. Plone4ArtistsVideo is mentioned once for podcasting support, but perhaps Plone4ArtistsAudio is meant, as that one is explained. In some cases, for example embedding YouTube videos, you need to write some pure html yourself, so enabling the tags is explained; I did not notice before that there was an embed-tab button that you can enable in Site Setup, Visual Editor, Toolbar. Again recommended for Mark as consultant and Fred as trainer. . Recommended for Esther (Partner), Robin (Marketing/Sales), Mark (Consultant), Fred (Trainer). This was a handy chapter for me as well; I just This chapter explains the Zope 2 way versus the Zope 3 way of theming. Depending on which parts of your site you want to style, you will need to learn both ways. You will learn about through-the-web versus development on the file system. You use paster for creating a basic theme product. Erik shows as the easiest way of overriding templates from Plone's sometimes difficult viewlet and portlet machinery. Recommended for Mirella and Laurens (CSS Specialists) for perhaps a better understanding of This is all about buildout, a zeo setup, CacheFu, Squid and Apache. Recommended for the programmers when dealing with Squid instead of the varnish that we mostly use; and a fresh look at the CacheFu settings would not hurt. The instructions to pack manually give wrong directions, which will have you end up in the ZMI in the Plone Site root, without a Zope Control Panel in sight. Instead you should simply go to Site Setup and then to Maintenance. Other than that, this chapter has no surprises, but if you come working for us as this is the first chapter you should read. Plone 3 for Education is a very practical book. It shows you a safe route through Plone land, giving solid advice that will keep you out of the pitfalls of this great CMS. Disclaimer: I got this book for free from Packt Publishing in exchange for a review. Ordering the book via one of the in this article will land me some money. [Less]

Using alternative template engines is a popular pastime these days and so I thought I'd give

we have our so-called "eten en weten" meetings; literally: eating and knowing, but in Dutch it rhymes. Basically it means: presentations by colleagues at the end of the afternoon, then food, then more presentations, with some discussions sprinkled ... [More] around. The later the evening, the more technical the presentations get, so the less technical colleagues can flee. :-) It is also a nice way to catch up with former colleagues who are invited; this time we were joined by Joris Slob; always a pleasure. Meet our strong It started off with Esther and Jean-Paul introducing new coaching options for the team members. Everyone gets the chance to have a few talks per year with a coach, paid for by Zest. The coaches were also there to introduce themselves. A very nice option. Then colleague Fred happily surprised us with a workshop about breathing techniques. In his spare time he sings in a choir, so he has experience here. Sorry, I don't think any pictures were taken. :-) Sun Sien Our CSS specialist Laurens showed some nice features he found on several websites. Ask him for some links. :-) , currently working at the Leiden Institute of Advanced Computer Science. He talked about the semantic web and the technologies that float around in that area. Web 1.0 can be summarised as: smart people put things on the web; less smart people only look at it. With web 2.0 lots more people can dump content, whether it is smart or not. But there is nothing fundamentally new about this web: it is just a different use of the same old techniques. For that you can look at what some call web 3.0: the semantic web. Computers currently do not understand the semantics of web pages. They fetch an html page and see something like this: blah blah blah blah blah blah blah blah important blah blah blah and you will get both cars and animals. But try Google's : it realises you could be looking for jaguar cars, jaguar parts, jaguar animals and more. As human you have knowledge. What do you do with that knowledge? Where do you store it? Can you put it in a database? Our databases do not fit this reality very well. In comes RDF, the Resource Description Framework. RDF offers user-defined relations, instead of a rigid database where all possible relations between items in tables have to be defined beforehand. RDF consists of triples: subject + predicate + object = fact. For example: Joris (subject) likes (predicate) Python (object). So the predicate is the relation between subject and object. But how do you know who this "Joris" is? Lots of people are called Joris, at least in The Netherlands. So you use a URI, a Uniform Resource Identifier, like this: This URI uses the Friend Of A Friend (foaf) vocabularies. These describe relations between persons. In this example we get an xml representation of the RDF triples, but they can also be stored in the native RDF non-xml format. Another part of the semantic web is OWL, the Web Ontology Language. (You may think this three letter acronym is in the wrong order, but the French would disagree with you; just ask our French colleague Vincent. Update: actually, see the section on the acronym in the for the real reason.) OWL gives greater expression possibilities. You also need reasoners. Reasoners can go through your knowledge base and find inconsistencies, or infer new relations. Fact 1: Joris is a human. Fact 2: humans have 2 legs. So we infer a third fact: Joris has 2 legs. Some inconsistencies can be resolved: "Obama is a good president" versus "Obama is a bad president" could become: 'John thinks "Obama is a good president"' and 'Lucy thinks "Obama is a bad president"'. Then there are ontologies. Ontologies define possible relations in a knowledge domain. Examples are SIOC, Dublin Core, Foaf, Good Relations and Basic Geo Vocabulary. If you can reuse an existing one, that is very good, as you do not want to create your own if you can avoid it. To get information out of a knowledge base, you can use SPARQL, which is a query language that looks a bit like SQL. To get everything, you would write: SELECT ?s, ?p, ?o where {?s ?p ?o} Another part of the semantic web is formed by microformats. These embed meaning in html. Examples are hCards, hCalendar, RDFa (pushed by Google, blocked by Adobe for HTML5). Also: Google Rich Snippets. This can for example be used to have information about ratings (4 out of 5 stars) show up in Google search results. For the python programming language you want to look at the rdflib library. Most readers of this blog will likely be familiar with Zope, so I'll mention that you can also use the ZODB (Zope Object DataBase) as a back end. Finally, if you want to learn more, you should read this book: , by Toby Segaran, Colin Evans and Jamie Taylor. At this time the non-technical people made good their escape, and the rest buckled up to learn about the wonderful world of jQuery, several jQuery libraries, and the soon to be released jQuery Proxy, made by Vincent. He made the presentation with live demos using Django; there was also a pony somewhere... The jQuery principle is: write less, do more. You usually do not have to care about differences between browsers. It has got great documentation. jQuery UI: the official UI for jQuery. It has themes, widgets, interactions (like draggable, droppable, resizable). jQuery Tools: less effects than jQuery UI, more web oriented, with tabs, tooltip, overlay, expose, scrollable. which is basically a pypi or CPAN for jQuery, including a demo for each plugin. Some that Vincent uses are cookie, color and lightbox. And now there is jQuery Proxy, written by Vincent. This gives easy integration of AJAX in python sites. At least it works in Django and Plone. You get jQuery syntax in python code and can send this back to the browser. It also allows using jQuery libraries/plugins. It could eventually replace KSS. The way you use it is for example this: from jquery.pyproxy.django import JQueryProxy, jquery # The @jquery decorator handles the transformation of your results # into JSON so we can decode it on client side. @jquery def ajax_add_comment(request): # The JQuery proxy object helps us to manipulate the page the user sees. jq = JQueryProxy() # The data/form sent with Ajax just apear like a classical POST form. form = request.POST #we do some validation of the form. ... if errors: # We display an error message. jq('#my_error_message').show() return jq ... # We display a success message. jq('#my_success_message').show() return jq and we will hopefully see a release next weekend. Very interesting! Next up was Mark, with a talk about Distributed Version Control Systems (DVCS), or as he liked to call it: . At Zest we are using subversion to store our code and share it among the developers. With subversion you have a central server that every commit goes to. But some would prefer doing local commits, so as not to disturb others with experiments or with a temporarily broken code state, or just because they are in a train and have no network connection. This is where distributed systems like git and mercurial or bazaar shine. You can still use a central repository if you want to though. With git you have a complete local repository, which means it is much much faster, as you need less network traffic: basically the only times you need to connect to a different server are when you pull code (get new code from trunk or a branch) and when you push code (send your changes to a server). Checking in code is fast, because you do not need to do get fresh code first () to see if someone else changed some code, so you also do not get clashes when checking in, and the commit is local so that makes it extra fast. Not everyone at Zest is sold on the idea of using git yet. For now we will keep using subversion. Those wanting to use git can use git-svn, and have been doing that already. If possible we'll try and keep our buildouts git-friendly; we have already created some client buildouts with the client packages directly in the buildout directory instead of including it using or (though the last one is apparently less of a problem). I was the last presenter of the evening. I talked about a client project, but there was a Non Disclosure Agreement involved, so I have probably already said too much. :-) So we will skip that and jump straight to my presentation about a new package I have created, called is a package that enables you to keep a list of people who want to receive emails when an item gets updated. The main use case is something like , which is an issue tracker for Plone. That product lets you create an issue tracker. In this tracker people can add issues. The tracker has managers. Every time a new issue is posted, the managers should receive an email. When a manager responds to an issue, the original poster (and the other managers) should get an email. Anyone interested in following the issue, should be able to add themselves to the list of people who get an email. also lie in the mentioned package, first created by Martin Aspeli and now maintained by me. A while ago I fixed some bugs in the email sending part of Poi, as sending can be tricky. After this, I thought this part of the code was quite solid (the rest as well, actually :-)) and could be useful for other packages that needed to send out email. So I decided to factor this code out into a separate package. This also made some parts of Poi cleaner and simpler. There is no release as of this writing, but the source code is in the that uses it. That branch of Poi is meant for Plone 4. I should create a proper alpha release for that soon. The package itself works just fine on both Plone 3.3 and 4, though there are some minor test failures on Plone 3. The test coverage is at a solid 98 percent, so I am quite sure most bugs have been ironed out. I showed what the package does by going through the code in the directory. For this blog entry I will resort to some copy-pasting from the readme file. It is not a package for end users. Out of the box it does nothing. It is a package for integrators or developers. You need to write some python and zcml in your own package (like Poi now does) to hook might also be usable as a basis for a newsletter product. If you feel is overkill for you, or too hard to adapt to your specific needs, you could try writing some code around Register an adapter from your content type to . In a lot of cases using the default implementation as factory for this adapter is fine: Create an html form where people can add themselves to the watcher list. Register a BrowserView for your content type, inheriting from and override its properties Create an event handler or some other code that gets the adapter for your content type and uses that to send an email with the subject and contents defined in the browser view you created. That is it. There are currently no viewlets, portlets or other templates that you need to override, so it should be easy to fit into the theme of your website, provided you do not mind coming up with a UI yourself. The directory is a good spot to look for the basis of that though. an option to send to all members (though this should already be very easy to do yourself), personalised emails, even if just with a footer to point to an unsubscribe option, optionally storing more info per subscriber, like a preference for plain text or html, more newsletter-like functionality, for example double-opt-in (similar to what the PasswordResetTool does when creating a Plone member). [Less]

we have our so-called "eten en weten" meetings; literally: eating and knowing, but in Dutch it rhymes. Basically it means: presentations by colleagues at the end of the afternoon, then food, then more presentations, with some discussions sprinkled ... [More] around. The later the evening, the more technical the presentations get, so the less technical colleagues can flee. :-) It is also a nice way to catch up with former colleagues who are invited; this time we were joined by Joris Slob; always a pleasure. Meet our strong It started off with Esther and Jean-Paul introducing new coaching options for the team members. Everyone gets the chance to have a few talks per year with a coach, paid for by Zest. The coaches were also there to introduce themselves. A very nice option. Then colleague Fred happily surprised us with a workshop about breathing techniques. In his spare time he sings in a choir, so he has experience here. Sorry, I don't think any pictures were taken. :-) Sun Sien Our CSS specialist Laurens showed some nice features he found on several websites. Ask him for some links. :-) , currently working at the Leiden Institute of Advanced Computer Science. He talked about the semantic web and the technologies that float around in that area. Web 1.0 can be summarised as: smart people put things on the web; less smart people only look at it. With web 2.0 lots more people can dump content, whether it is smart or not. But there is nothing fundamentally new about this web: it is just a different use of the same old techniques. For that you can look at what some call web 3.0: the semantic web. Computers currently do not understand the semantics of web pages. They fetch an html page and see something like this: blah blah blah blah blah blah blah blah important blah blah blah and you will get both cars and animals. But try Google's : it realises you could be looking for jaguar cars, jaguar parts, jaguar animals and more. As human you have knowledge. What do you do with that knowledge? Where do you store it? Can you put it in a database? Our databases do not fit this reality very well. In comes RDF, the Resource Description Framework. RDF offers user-defined relations, instead of a rigid database where all possible relations between items in tables have to be defined beforehand. RDF consists of triples: subject + predicate + object = fact. For example: Joris (subject) likes (predicate) Python (object). So the predicate is the relation between subject and object. But how do you know who this "Joris" is? Lots of people are called Joris, at least in The Netherlands. So you use a URI, a Uniform Resource Identifier, like this: This URI uses the Friend Of A Friend (foaf) vocabularies. These describe relations between persons. In this example we get an xml representation of the RDF triples, but they can also be stored in the native RDF non-xml format. Another part of the semantic web is OWL, the Web Ontology Language. (You may think this three letter acronym is in the wrong order, but the French would disagree with you; just ask our French colleague Vincent. Update: actually, see the section on the acronym in the for the real reason.) OWL gives greater expression possibilities. You also need reasoners. Reasoners can go through your knowledge base and find inconsistencies, or infer new relations. Fact 1: Joris is a human. Fact 2: humans have 2 legs. So we infer a third fact: Joris has 2 legs. Some inconsistencies can be resolved: "Obama is a good president" versus "Obama is a bad president" could become: 'John thinks "Obama is a good president"' and 'Lucy thinks "Obama is a bad president"'. Then there are ontologies. Ontologies define possible relations in a knowledge domain. Examples are SIOC, Dublin Core, Foaf, Good Relations and Basic Geo Vocabulary. If you can reuse an existing one, that is very good, as you do not want to create your own if you can avoid it. To get information out of a knowledge base, you can use SPARQL, which is a query language that looks a bit like SQL. To get everything, you would write: SELECT ?s, ?p, ?o where {?s ?p ?o} Another part of the semantic web is formed by microformats. These embed meaning in html. Examples are hCards, hCalendar, RDFa (pushed by Google, blocked by Adobe for HTML5). Also: Google Rich Snippets. This can for example be used to have information about ratings (4 out of 5 stars) show up in Google search results. For the python programming language you want to look at the rdflib library. Most readers of this blog will likely be familiar with Zope, so I'll mention that you can also use the ZODB (Zope Object DataBase) as a back end. Finally, if you want to learn more, you should read this book: , by Toby Segaran, Colin Evans and Jamie Taylor. At this time the non-technical people made good their escape, and the rest buckled up to learn about the wonderful world of jQuery, several jQuery libraries, and the soon to be released jQuery Proxy, made by Vincent. He made the presentation with live demos using Django; there was also a pony somewhere... The jQuery principle is: write less, do more. You usually do not have to care about differences between browsers. It has got great documentation. jQuery UI: the official UI for jQuery. It has themes, widgets, interactions (like draggable, droppable, resizable). jQuery Tools: less effects than jQuery UI, more web oriented, with tabs, tooltip, overlay, expose, scrollable. which is basically a pypi or CPAN for jQuery, including a demo for each plugin. Some that Vincent uses are cookie, color and lightbox. And now there is jQuery Proxy, written by Vincent. This gives easy integration of AJAX in python sites. At least it works in Django and Plone. You get jQuery syntax in python code and can send this back to the browser. It also allows using jQuery libraries/plugins. It could eventually replace KSS. The way you use it is for example this: from jquery.pyproxy.django import JQueryProxy, jquery # The @jquery decorator handles the transformation of your results # into JSON so we can decode it on client side. @jquery def ajax_add_comment(request): # The JQuery proxy object helps us to manipulate the page the user sees. jq = JQueryProxy() # The data/form sent with Ajax just apear like a classical POST form. form = request.POST #we do some validation of the form. ... if errors: # We display an error message. jq('#my_error_message').show() return jq ... # We display a success message. jq('#my_success_message').show() return jq and we will hopefully see a release next weekend. Very interesting! Next up was Mark, with a talk about Distributed Version Control Systems (DVCS), or as he liked to call it: . :-) At Zest we are using subversion to store our code and share it among the developers. With subversion you have a central server that every commit goes to. But some would prefer doing local commits, so as not to disturb others with experiments or with a temporarily broken code state, or just because they are in a train and have no network connection. This is where distributed systems like git and mercurial or bazaar shine. You can still use a central repository if you want to though. With git you have a complete local repository, which means it is much much faster, as you need less network traffic: basically the only times you need to connect to a different server are when you pull code (get new code from trunk or a branch) and when you push code (send your changes to a server). Checking in code is fast, because you do not need to do get fresh code first () to see if someone else changed some code, so you also do not get clashes when checking in, and the commit is local so that makes it extra fast. Not everyone at Zest is sold on the idea of using git yet. For now we will keep using subversion. Those wanting to use git can use git-svn, and have been doing that already. If possible we'll try and keep our buildouts git-friendly; we have already created some client buildouts with the client packages directly in the buildout directory instead of including it using or (though the last one is apparently less of a problem). I was the last presenter of the evening. I talked about a client project, but there was a Non Disclosure Agreement involved, so I have probably already said too much. :-) So we will skip that and jump straight to my presentation about a new package I have created, called is a package that enables you to keep a list of people who want to receive emails when an item gets updated. The main use case is something like , which is an issue tracker for Plone. That product lets you create an issue tracker. In this tracker people can add issues. The tracker has managers. Every time a new issue is posted, the managers should receive an email. When a manager responds to an issue, the original poster (and the other managers) should get an email. Anyone interested in following the issue, should be able to add themselves to the list of people who get an email. also lie in the mentioned package, first created by Martin Aspeli and now maintained by me. A while ago I fixed some bugs in the email sending part of Poi, as sending can be tricky. After this, I thought this part of the code was quite solid (the rest as well, actually :-)) and could be useful for other packages that needed to send out email. So I decided to factor this code out into a separate package. This also made some parts of Poi cleaner and simpler. There is no release as of this writing, but the source code is in the that uses it. That branch of Poi is meant for Plone 4. I should create a proper alpha release for that soon. The package itself works just fine on both Plone 3.3 and 4, though there are some minor test failures on Plone 3. The test coverage is at a solid 98 percent, so I am quite sure most bugs have been ironed out. I showed what the package does by going through the code in the directory. For this blog entry I will resort to some copy-pasting from the readme file. It is not a package for end users. Out of the box it does nothing. It is a package for integrators or developers. You need to write some python and zcml in your own package (like Poi now does) to hook might also be usable as a basis for a newsletter product. If you feel is overkill for you, or too hard to adapt to your specific needs, you could try writing some code around Register an adapter from your content type to . In a lot of cases using the default implementation as factory for this adapter is fine: Create an html form where people can add themselves to the watcher list. Register a BrowserView for your content type, inheriting from and override its properties Create an event handler or some other code that gets the adapter for your content type and uses that to send an email with the subject and contents defined in the browser view you created. That is it. There are currently no viewlets, portlets or other templates that you need to override, so it should be easy to fit into the theme of your website, provided you do not mind coming up with a UI yourself. The directory is a good spot to look for the basis of that though. an option to send to all members (though this should already be very easy to do yourself), personalised emails, even if just with a footer to point to an unsubscribe option, optionally storing more info per subscriber, like a preference for plain text or html, more newsletter-like functionality, for example double-opt-in (similar to what the PasswordResetTool does when creating a Plone member). [Less]

Filed under:

After 14 years, Zope community has created a . Congrats to Christian Thueni (gocept.com) for working on the site.

Packt Publishing just made available the first book on Grok development, by Carlos de la Guardia.

---

---