Zope

Note beforehand. Martijn Faassen is well known in the zope world. Remember zope? The python web framework that used to have the buzz that django has now? I remember two europython conferences where one of the three tracks was ... [More] zope/plone-only. Those europython conferences were one of the things he started, btw. So I expect a bit of a history lesson and some valuable input from another python web framework and perhaps some community organizing comparisons. We'll see! Now on to the actual summary. Martijn wrote/started a couple of things: formulator, five (zope3 in zope2), lxml, grok webframework, etc. He started python programming in 1998. And around that time he also started with zope: yes, it is that old. In 2008 at djangocon, there was a talk by Mark Ramm about what django could learn from zope. Matt is a turbogears guy, btw. The reactions were pretty harsh sometimes, like "we lost a whole generation of web programmers to zope" and "django is an anti-zope". Some inflammatory comments to start off the discussion in the internet forums. Just to get it over with :-) Django now has class-based views. Zope's class based views are from 2004. (In his presentation he called it generic views, btw). Django's unicode support is from 2007. Zope's was 2002. NoSQL is popular right now. Zope had the nosql zodb database from the start. Na na na na na :-) Summary: django is great, but we could still learn a bit from zope. Also from the mistakes. The start of zope was on a plane with Jim Fulton heading out to teach a cgi programming class in 1996. He thought it could be more object oriented so he started coding... Zope was open sourced by the company (Digital Creations) in 1998. At the time it was Huge News! A small company open sourcing its product! That didn't happen often! It wouldn't be news now, but it was at the time. A core item from zope: object publishing. A URL is interpreted as a path to a model in a model hierarchy (=tree structure). Much like with a filesystem path, but with objects. When the model is found, it must be rendered for the web with a view. The tree traversal is also useful for security, again just like with a filesystem. The object itself knows where in the tree it is and so it knows its url. In contrast, django uses url pattern matching. The url points at a view function which renders something. The function might grab some objects from the ORM. In zope, a view is given a model and renders it. In django, the view itself looks up the model. What's the advantage of such a tree traversal mechanism instead of url pattern matching? You can design your app around your models. You can design generic, reusable views. For instance a generic, default "edit" view. You can compose and recombine models without having to map or remap lots of URLs. In practice: you can stick anything in every kind of folder if you need it. And you can have virtually infinite nesting. You can more easily add a view in one app for a model defined in another app. There is also a drawback: More indirection. You cannot look up a urls.py with full info about which goes where. Now some comments about community. Zope 10 years ago had meetups, BBQs, sprints. Zope was popular. Conferences like europython gained many visitors because of people coming for the zope track. Many python developers came to python through zope. There was a disconnect between zope and the regular python community. Zope did things their own way, partially out of necessity. Some of those ways later turned out to be un-pythonic, but some of the zope solutions ended up in python itself! A big problem was zope's Z-shaped learning curve (that's NOT how you want your learning curve to be). Easy to start out with, but after a while... Pythonic: lack of pythonicity makes it hard to get into python coming from plone. Or harder to get from python to zope. But python changes, so what's pythonic changes. Take module names for instance. They're lowercase now. Zope is old enough to still have CamelCase.py module names. On the other hand, some zope things like metaclasses even ended up in python itself, so that's more pythonic now. Django is pretty pythonic. But wsgi is now the pythonic thing and django doens't do it that fully. And external dependencies are pythonic now and django has a lot build-in. So django is also slowly becoming more un-pythonic. Zope's answer to the un-pythonicity was a complete rewrite. Zope2 became zope3. Summary: don't do a total rewrite, do it in an incremental way. Some of the ideas and fixes were good. Some, like xml configuration files, were bad and unpythonic. Even though the ideas behind it were good. Configuration as such is good. It allows you to change things more easily. But don't do it in xml files. But also watch out when doing it in python: you can easily get cyclic import conflicts. But if you do it right, you can combine and recombine configuration. This "doing it right" was the basis for the grok project. It took ideas from rails and from django. Both offered a much friendlier face to the developers than zope did. With a couple of decorators they managed it. Check out Martian. Sometimes Martijn gets a deja-vu from django. Zope is sometimes ahead in the future (like with unicode and class-based views). So he can give some messages from django's future. Watch out with dependencies. Make sure that in a big system, pulling in one part doesn't automatically pull in everything else in one big tangled mess. Drop dependencies if you don't need it. Django doesn't have packages, but the module level graph is pretty big and scary. He did some by-hand checking of the django code on the django.subpackage level. Lots of circular imports! You could not distribute django.views seperately if you'd want. It pulls in everything. Is cleaning this up a good idea? Could you split up django? Would you want to? Would you want to split out django.db? Would you want to be able to replace or swap parts of django? Or upgrade one part separately? And... do you want other people to reuse individual bits of django? Like the orm? Or do you want a repeat of the jinja2-scenario? Zope DID split things up, partially with the hope that other python developers would grab bits and pieces of zope. The success is mixed. Some parts are re-used, others aren't hardly touched. The most important outcome to zope is we're less insular, more connected to python-as-a-whole. And zope suffers less from the not-invented-here syndrom. And Not Invented Here is a danger. It can lead to a lack of reuse. And you learn less from others as you don't look at other stuff anymore. If you read the django FAQ about the lack of reuse of generic packages the answer sounds to Martijn like "NIH NIH NIH NIH". Zope has invested a lot in integrating with python as a whole. WSGI. Python packaging. Lots of cross-pollination is happening. Lots of reuse. Less duplication. Using the best available libraries. Your own code also becomes better if you turn it into a generic reusable libraries. And Martijn could then perhaps use cool django stuff without needing all of django. Some libraries you might be interested in for reuse: Traject, it tries to combine object traversal with URL pattern matching. URL pattern matching to objects instead of to views, btw! Fanstatic (not "fantastic"). There's django integration: https://bitbucket.org/fanstatic/django-fanstatic . A much simpler way to handle css/js dependencies. Resource bundling, smart cache invalidation and so. Obviel is a model/view/element system for client-side javascript. Build on jquery. Basically he brainstormed on using zope ideas for client side javascript, as a lot happens there nowadays. Restful json. It helps organize complex client-side applications into components. Good integration with client-side template systems. System Message: WARNING/2 (, line 177); backlink Duplicate explicit target name: "grok". If you want to check out some zope ideas: look at grok or at pyramid. [Less]

The new members are:    * Timo Stollenwerk of Bonn, Germany    * André Nogueira of Simples Consultoria in São Paulo, BrazilThe Plone Foundation is the organization formed in 2004 to serve as a supporting organization for Plone and its community. ... [More] Members of the Foundation are chosen by the Foundation's Membership Committee on the basis of merit - specifically that they have made significant, enduring contributions which benefit the general Plone community.The Foundation is happy to welcome Timo and André as members! [Less]

Three CMSs got 10 minutes each for a presentation: Merengue by Manuel Saelices Django CMS by Jonas Obrist Fiber by Dennis Bunskoek (see also my summary of a Dutch django meeting talk about fiber). Fiber Fiber is a simple and ... [More] user-friendly CMS that they use in almost all their django projects. He showed a screencast with fiber in action. It got across the usability and friendliness of Fiber quite nicely. Originally they used django flatpages with a whole bunch of add-ons for tree viewing and menus, but it didn't feel like one coherent whole. So they made Fiber which will integrate quite nicely with your existing project. It is not a lot of code. 1601 lines of python and 2091 of javascript. ("Should we even be at this conference, there's more javascript than python!"). The output is clean html with handy css classes. A couple of template tags makes it easy to write your templates. TODO: Front-end editing for your models. More control over placement of content including more sorting/filtering. More plugins for video, twitter and so. They'll make UI/UX improvements: a designer will look at it in the next weeks. A demo project. More translations (NL and EN are available right now). Internationalisation (some people are working on it). Django Fiber from Ride The Pony on Vimeo. Django-cms The core to django-cms are pages. The content itself are placeholders where plugins are plugged into. Integration of your existing django apps with django-cms is important, this is done by means of "apphooks". Django-cms is build to be extended, so it is both a ready-made app and a framework. CMS has full django multi-site support. And, very important for them as a Swiss company, is multilinguality. Their worst-case site has 18 different websites with each a different combinations of 26 languages! There's editorial workflow with permission management. Front-end editing. Almost as cool as Fiber's (and they're working on it). An important extension mechanism is the "app hook": you integrate your app with django-cms with a specially-named auto-detected python file that can configure a submenu structure, a view, a sub-urls configuration. Likewise, plugins are in a cms_plugins.py. You can plug those into slots in the page. The plugin defines what it is and how to render it. By hooking in a separate admin, you can get front-end editing for your own models. Django-cms is pretty big. 170+ contributors. 1000+ watchers, 300+ forks. Fully translated into 17+ languages. Dozens of apps. They have a dedicated front-end developer now so that should help in getting the UI better and the javascript cleaner. They hope to get multi-device support going for the 2.3 version of django-cms. And they hope to get the existing toolbar more extensible so that it is easier for other apps to re-use and extend. See http://bit.ly/djangocms-demo for a demo you can play with! Merengue Plone, which they used earlier, is an amazing and great python CMS, but also big and harder to understand. Then they discovered django. Clean, simpler, easier. But no CMS. So they had to add a CMS of their own: Merengue. He demoed it live on his laptop. It worked without hickups! Important to them is front-end editing and moving blocks of content around on the page with javascript. Very dynamic. Also doable via the web interface: adding cache settings per block. Even translations are done via the web interface. Handy feature: you can get translatable items highlighted for you so that you know what's left to translate. They've also done their best to pimp the regular django admin interface. Build-in is for instance django-compressor for js/css combining and compression. There are many more existing apps that they use. [Less]

The Plone security team is sorry to announce that a flaw in Hotfix20110531 released on the 1st June 2011 has been found.  The escalation of privileges attack was not blocked on Plone 4, despite having the fix installed.  As such, we have released ... [More] version 2.0 of this fix which contains a tighter check for potential attacks, which is available at http://plone.org/products/plone-hotfix/releases/20110531. If you have already installed Hotfix20110531 on Plone 4 you need to update to version 2.0.  For Plone 3.x and Plone 2.x, if Hotfix20110531 is not yet installed you should install version 2.0.  If you have version 1.0 of Hotfix20110531 installed on Plone 3.x or 2.x you do not need to upgrade. For those who used buildout to install the fix all that needs be done is for it to be re-run to pick up the latest versions. We apologise for the inconvenience this has caused; we will be doing a postmortem on this fix to further improve our security patch release procedures in the coming weeks. [Less]

This is a reflected cross site scripting attack, that is, it is exploitable by special URLs that contain the malicious content.  This vulnerability was responsibly disclosed by J. Greil after discovery by S. Streichsbier, both of SEC Consult. Fix ... [More] The Hotfix for this vulnerability is Hotfix 20110531. *** IMPORTANT ***: The original release of this hotfix that was made on May 31 had a critical flaw.  Please make sure you are using version 2.0 of the hotfix. The Plone security team apologizes for the error.   Information for security researchers CVSS Base Score 9.7 Impact Subscore 9.5 Exploitability Subscore 10 Overall CVSS Score 7.2 [Less]

This is a persistent cross-site scripting (XSS) attack. It allows a user to craft markup that bypasses Plone's safe_html filter to insert and save arbitrary HTML with malicious content. This vulnerability was discovered and responsibly disclosed by ... [More] Daniel Berlin and Dan Bentley, both of Google, and independently by Brian Peters, an independent researcher. Fix The Hotfix for this vulnerability is Hotfix 20110531. *** IMPORTANT ***: The original release of this hotfix that was made on May 31 had a critical flaw.  Please make sure you are using version 2.0 of the hotfix. The Plone security team apologizes for the error.   Information for security researchers CVSS Base Score 9.7 Impact Subscore 9.5 Exploitability Subscore 10 Overall CVSS Score 7.2   [Less]

This is an escalation of privileges attack which makes it possible for an authenticated Plone user to edit the properties of other users, bypassing authorization checks. As this vulnerability was disclosed publicly it is highly recommended that all ... [More] site administrators and their privileged users reset their passwords. Fix The Hotfix for this vulnerability is Hotfix 20110531. *** IMPORTANT ***: The original release of this hotfix that was made on May 31 had a critical flaw.  Please make sure you are using version 2.0 of the hotfix. The Plone security team apologizes for the error.   Information for security researchers CVSS Base Score 9 Impact Subscore 10 Exploitability Subscore 8 Overall CVSS Score 6.7 [Less]

This is an escalation of privileges attack which makes it possible for an authenticated Plone user to edit the properties of other users, bypassing authorization checks. As this vulnerability was disclosed publicly it is highly recommended that all ... [More] site administrators and their privileged users reset their passwords. Fix The Hotfix for this vulnerability is Hotfix 20110531.   Information for security researchers CVSS Base Score 9 Impact Subscore 10 Exploitability Subscore 8 Overall CVSS Score 6.7 [Less]

This is a persistent cross-site scripting (XSS) attack. It allows a user to craft markup that bypasses Plone's safe_html filter to insert and save arbitrary HTML with malicious content. This vulnerability was discovered and responsibly disclosed by ... [More] Daniel Berlin and Dan Bentley, both of Google, and independently by Brian Peters, an independent researcher. Fix The Hotfix for this vulnerability is Hotfix 20110531.   Information for security researchers CVSS Base Score 9.7 Impact Subscore 9.5 Exploitability Subscore 10 Overall CVSS Score 7.2   [Less]

This is a reflected cross site scripting attack, that is, it is exploitable by special URLs that contain the malicious content.  This vulnerability was responsibly disclosed by J. Greil after discovery by S. Streichsbier, both of SEC Consult. Fix ... [More] The Hotfix for this vulnerability is Hotfix 20110531.   Information for security researchers CVSS Base Score 9.7 Impact Subscore 9.5 Exploitability Subscore 10 Overall CVSS Score 7.2 [Less]