Zope

Dear world,this is your Zope 2 release manager speaking. We had some discussion in the community about the roadmap ahead for the next Zope 2 release culminating in a plan today.A first alpha release for Zope 2.13 will be released on June 25 - just ... [More] over 10 days from now. More alpha releases will follow on a 3-4 weeks basis and a first beta will be out in early September. That is as usual without guarantees and subject to changes. A final release is expected later this year.Zope 2.12 is continuing to be maintained. A Zope 2.12.7 bugfix release was released just yesterday.Current Zope SVN trunk (which will become 2.13) is compatible with both CMF 2.2 and CMF trunk and the upcoming Plone 4. It is likely that Plone 4.1 will officially support Zope 2.13.Zope 2.13 will bring a couple new features and has done a large deal of refactoring and house keeping. It currently only supports Python 2.6. Support for Python 2.7 might be added, if there is community volunteers to do the required work. Python 3.x support is out of the scope. Work has begun to port some of the underlying zope packages to Python 3.x, but there's still a lot more to do before this is feasible for Zope 2 itself.So what's in it?Zope 2.13 doesn't have any zope.app.* dependencies anymore. This finishes the transition from the hybrid Zope 2 + 3 codebase. Zope 3 itself has been split up into two projects, the underlying Zope Toolkit consisting of foundation libraries and the application server part. The application server part has been renamed BlueBream. Zope 2 only depends and ships with the Zope Toolkit now. Large parts of code inside Zope 2 and specifically Products.Five have been refactored to match this new reality. The goal is to finally remove the Five integration layer and make the Zope Toolkit a normal integral part of Zope 2.Zope 2.13 comes with native WSGI support. First pioneered in the repoze.zope2 project, this capability finally found its way back into the core and obsoletes the externally managed project. With WSGI Zope 2 can natively talk to a variety of web servers and isn't restricted to its own ZServer anymore. It also opens up new possibilities for writing or reusing middleware in Zope 2 or factoring out capabilities into WSGI endware. It's expected that this new deployment model will over time become the default and the old ZServer implementation will be deprecated. There's no concrete timeline for this yet.There's an ongoing effort to refactor Zope 2 into more independent modularized distributions. Zope 2.12 has already seen a lot of this, with the use of zope.* packages as individual distributions and the extraction of packages like Acquisition, DateTime or tempstorage to name a few. Zope 2.13 continues this trend and tries to externalize packages containing C extensions. In a not so distant future it should be possible to run a Zope 2 like environment without the ZMI and the corresponding code. This is part of the vision for Zope 2 to evolve into a more modern and maintainable codebase, while preserving a realistic gradual upgrade path for existing installations and projects based on it. The Zope 3 project has shown that a complete rewrite is no viable answer for a large class of existing software.There's a large number of smaller features and improvements in the underlying libraries and Zope 2 itself. For example Zope 2.13 will ship with the new ZODB 3.10 version, which sports some noticeable performance improvements. The move to the latest version of the Zope Toolkit libraries makes integration of Zope community projects like z3c.form much easier.After the rather long release periods of Zope 2.12 and 2.13 we expect to switch to a shorter release period of six to nine months for the upcoming 2.14, 2.15 and beyond releases.Discussion of the Zope 2 core development takes place on the zope-dev mailing list. Feel free to engage, leave comments on this blog or contact me in private.Your release manager,Hanno [Less]

I little suspected the great chasm that lies between the simple act of agreeing to review a book, and the actual exercise of sitting down later to write the review. It feels quite pleasant, really, to jot off a positive reply to the ... [More] publisher's polite question. One feels magnanimous for agreeing to help advance our civilization by reviewing a book about Python, and for helping out the publisher in what, after all, are such hard economic times. It is fun when the free copy arrives, crisp and smartly bound. But then, eventually, one has to write the actual review. And so, a full four months after that friendly email from Packt Publishing, it is time that I sit down and put together some thoughts about Carlos de la Guardia's first book, Grok 1.0 Web Development. Carlos is a long-time veteran of the Zope and Plone communities, and Grok, of course, is the web framework that places a simple and agile convention-driven engine atop the otherwise notoriously XML-ridden Zope application framework. Grok is an important project, because it packages the technology of Python's oldest and most experienced community of web developers in a way that makes it easy to extend and use. (...)Read the rest of Grok has book. Book good! (814 words) [Less]

Djangocon.eu 2011 news Djangocon.eu 2011 is going to be organized in... Amsterdam! My djangocon.eu summary I opened the evening with a summary of last month's djangocon.eu conference. I won't write down a summary of the summaries that ... [More] I already made of all the talks :-) Some main points: Go to such a conference! Good experience. What to do? How to get there? What happens? Django's own development. The django technical panel, Jacob's keynote, the bad pony talk, etc. NoSQL. A big hit at the conference with 3 talks and 1 panel. Some links I gave: My summaries. The videos of all the talks. Idan Gazit's design for developers talk. Read it or, better, watch the video. Highly recommended. www.academictransfer.com (Jan Murre) Subtitle: "an academic Jobboard with Django. Also featuring: Plone and SOLR". Academictransfer is a spin-off from the VSNU, the combined Dutch universities. Academic transfer has a lot of academic jobs in the Netherlands and they're expanding abroad. It is really focused on academic jobs. Pareto, his company, uses Plone a lot. Plone is a really good content management system, but people sometimes abuse it for tasks for which it is not suited. Since a few years, they use Django for those kind of non-Plone-suited projects. The old side was a 10-year old coldfusion site. A classic case of vendor lock-in of the company that build them the original site. Performance problems and big problems at every change request. They originally asked Pareto for a Plone website ("it is a lot of content"). Plone is a good CMS, but this is mostly a database-driven site, so they advised Django. They also use SOLR. SOLR is a high-end open source search engine (from the apache world). Till now, this has proven to be a good choice. They use buildout (YEAH! See my buildout articles). It is their workhorse for setting up Django websites. With a buildout config, you can have a fresh, running django website within a minute. (Note: read Jacob Kaplan-Moss's article about Django and buildout). People are looking for a job, so the search functionality is the most important part of the site. SOLR works great. It is good at searching with facets. A facet can be an organisation or a keyword or an academic field for instance. There's login and personalization. Storing your queries; getting mails with new vacancies. Universities also can have their own page in the site. Most of the website is made with Django, but Plone is also used. An apache config divides up the requests between the both of them. The UI is reused between Django and Plone. They did this by having Django ask plone for a base template. What plone returns is a plone browser view, but it is a Django template with Django's tags! The base template is downloaded with a cron job every night as the Plone site doesn't change that much. Another option would have been deliverance. Nice system. A localization problem: Plone and Django use different methods for setting the language. Django stores it in the session and Plone uses a separate i18n cookie. The solution was to do the language switching on the Django side and get Django to set the Plone cookie, too. (An alternative could have been some django i18n middleware). User management is Django-only. In the Plone pages, you want to show the username, too, though. The solution was to add an ajax call to the Plone interface that asks Django for the username :-) The whole website is cached with varnish (which is basically the standard in the Plone world). For the username stuff, they had to use aggressive cache invalidation. An alternative they're going to pursue is SSI (server side includes). A main reason is that such ajax injection goes against the webrichtlijnen (Dutch accessibility guidelines). They want to show some Django content, like recent job entries, in the Plone homepage. The solution: load those entries via RSS/Atom feeds in Plone portlets. You have to make those feeds anyway. Website statistics are of course important. The counters are stored in a Redis store. Redis is a very simple noSQL database that's basically only a key/value store. Lightning fast. It uses http for connections. He had some doubts about that, but it turns out to be fast, too. Google analytics wasn't an option as academic transfer had some custom requirements. Especially very custom "funnels". Funnels are specific sequential steps that a customer can take through the site. Some extra features: Pluggable publication model so that you can submit to/from several university's job sites. Chinglish plugin: automatic English-Chinese translation. The quality isn't perfect, but it suffices to get translated job vacancies into China's main "baidu" search engine. The people that find it then can switch to English for the "real" job vacancy. Several import/exports. Question: when would you use Django, when Plone? Answer: for this site, they'd have gone with all-Django. Plone is only used for only 15 pages. But if your site needs real CMS functionality, use Plone. So if you need workflows, per-page and per-folder security, stuff like that. Don't build anything like that yourself: it is already there in Plone. Lightning talks Updating your django site, the easy way (Dave de Fijter) When you update your site, there are a lot of manual steps you need to do. That's not DRY (don't repeat yourself). Some options: Shell scripts (but you still need ssh). Fabrik (pretty good, but not that friendly) He proposes django-siteupdate. You can update your sites from the django admin. It keeps logs of your updates. Custom update scripts are possible, as is postprocessing. You see the output of your scripts in the django admin interface. (I mentioned a djangocon talk about capistrano.) Dynamic models in Django (Joeri Bekker) Dynamic models are not defined in your python code. For instance, they're created on the fly at runtime. You could create a flexible admin this way. Or you can dynamically prototype models without having python knowledge. Or you can, before a syncdb, create dynamic copies of your old data models so you can still access them. Or, what he uses it for, generate additional models for localization. How? Something like: Person = type('Person', models.Model, attrs={..field...}) In the end, it is more involved of course. Most of django's machinery still works just fine with those classes. You can run syncdb just fine from within your code, creating the tables in your database. So: do you have a usecase for this? He said there was a nice article about this subject on the Django website. My App Engine has more horsepower than your Pony (Alper Cugun) Alper's been programming Django for 5 years. Recently he's working with google's app engine. Django is good for content-heavy websites and for complex websites that are composed of many apps. App engine is made for scalability and availability. The good things about app engine: The database (nosql!) is great. SQL sucks. NoSQL doesn't give you migrations, so you don't have migration issues :-) There's a python script that deploys to google in no time. No configuration, only programming. It just works. App engine comes with batteries included. Memcache and all sorts of other tools. Handy. Google makes sure it is scalable and always available and safe. The bad things: No serious queries. No normalization. Partially bad, but it enables some of the good things. There's a 30 second deadline for everything. Something that takes to long doesn't ever complete. They are a bit focused on enterprisey stuff. Some tips: use indexes, memcache and create json endpoints. It is ideal for getting stuff up and running quickly. Instant gratification. He wouldn't really tie his whole company to google at the moment. Just a millisecond, achieving performance without ramping up the hardware (Rick van Hattem & Thierry Schellenbach) They got way too much traffic to one of their sites (http://www.fashiolista.com/) as it got waaaay to popular. A default approach is to cache pages in Django: the @cache_page decorator. NGINX and memcached are also a great combination. Their problem: most of the content is user-specific and thus uncacheable. The solution: combination of SSI (server side includes) and javascript. Memcached stores an anonymous page and the javascript knows how to turn it into a personalized page. SSI mixes in a bit of data with personalization instructions into the page. Javascript then applies those instructions. This SSI mixed-in data is just a very small Django request. He showed result statistics that were pretty sweet. A bigger tutorial and code will be up soon at http://mellowmorning.com Class based views (Roald de Vries) His goal was to find an object oriented way to create reusable views for his project. Django had almost the same goal for its "generic views". He used the __init__() method and django is starting to use the __call__() method. The __call__() calls the actual methods that you can override in subclasses. The url pattern is a problem. Thread-safety is an issue, they're still thinking about an optimal solution. An advantage of his __init__ method is that the url pattern can stay the same. There are some disadvantages with subclassing and returning self. Search the django developer mailing list for "class based generic views in 1.3" to get the full discussion. [Less]

A Seminar and Conference websites built on Plone

If you are using Plone 3.3 or older you are probably suffering an expensive security check when creating an Archetype. It can be EASILY fix.

Adds a doormat viewlet and installs in in the Plone footer. The links in the doormat are manageable as content.

collective.blog.*, or just blog.star, for short, is a suite of blogging modules for Plone. It is primarily designed for integrators. Most people who use Plone for blogging also uses Plone as a customized content management system, and they have ... [More] specific requirements and their own skin, custom content types and other integrations. It turned out that other Plone blogging products make a lot of assumption about how you are to use it, what you want from a blog, and how your site is set up. blog.star follows a set of principles to avoid these problems: Be modular. Not everyone wants everything your blogging software has to offer. Be flexible. Don’t assume that people want to use your software in one particular way. Be simplistic. If there is a simple way of doing it, do it that way. Be Ploneish. Plone already has 90% of what a blog needs built in. Use it. Modular blog.star is made up of several separate modules, that each do one thing only. The modules so far is: collective.blog.view: Provides a blog-style view for Plone folders and collections, with support for use in monthly archives. collective.blog.feeds: Uses basesyndication and fatsyndication to provide several types of XML/RDF feeds for fodlers/collections. collective.blog.portlets: Portlets useful for blogging, such as a monthly archive and a last posts portlet. collective.blog.star: A module that uses all of the above plus some extra modules like qi.portlet.tagClouds useful for blogging. Use this is if you just want simple blogging support in Plone. The development of collective.blog.star was sponsored by Jarn AS – http://www.jarn.com Flexible If a portlet would work great in a normal folder, why shouldn’t it? There is no need to add the arbitrary requirement that your portlets only works in folders that have a specific marker interface, for example. Marker interfaces are there to mark an object as being something special, even though that “special” doesn’t need a separate interface. Now a blog is just a container of blog entries with a blog view and archives etc. There is no reason any of your “blog” portlets would only work with a folder that is marked as being a blog. The portlets I’m writing for blog.star will work in any folder or collection. Simplistic The blog view doesn’t require anything particular from the blog entries, as long at they are archetypes objects. If they aren’t, well, then you need to make your own blog entry view, something you might want to do anyway, to control how they look in detail. Doing it is easy, you just create a view called blog_item_view for your content type. Ploneish Yes, you can configure Plone so that an objects default view becomes a special blog view when you set a marker interface on that object. But you can also just add the view to the list of allowed views in the portal type, and select the view from the view drop down. It’s simpler, more easily configurable, because you can now add that view even to custom folder types that you may have without digging into the code and figuring out what marker interface to put where. This is how the blog view of collective.blog.view works. Installation To install blog.star you simply add “collective.blog.star” to the list of eggs in your buildout, run buildout and restart the Plone server. In Plone’s portal_quickinstaller you select “blog.star” and install it. I’ve tested it on Plone 3.3.4 and 4.0b3. Now you can create a normal folder, and in the Display menu you can select “Blog view” to make the folder into a blog. You add blog entries with the standard Page type, and you can even create podcast entries with the standard File type. You also have a set of new portlets available, like a Monthly Archive, a Last Entries and a Tag Cloud portlet. And yeah, that’s it! Filed under: python [Less]

A new San Francisco / Bay Area Plone Meetup kicks off this Thursday, June 3.

RedTurtle is participating each year in Sorrento's Plone sprints. We were there also last week. It was an amazing time of brainstorming and coding. I will try to make a summary of what we have archived.

After 6 years in Paris, and three as an independent subcontractor it’s time for me to move on in several ways. I’ve been a full time programmer for 14 years, the last nine doing python web applications. The last few years I’ve been able to gain ... [More] experience not only in programming, but hosting, managing large sites and other related technologies to be able to both guide customers to what they really need, and judge what technologies to use. I have a good stack of technologies in my bag that will make everything from small projects to large behemoths doable, and I know at least how to not run projects, which counts for a whole deal. So me and my friend Johan Carlsson, has decided to reboot Colliberty. Colliberty was started in 2003, in between the collapse of the company I then worked for (Torped) and before I got a job for Nuxeo in Paris. And since I got a job, the company has been mostly resting, mainly we have taken care of Torped’s old customers through this company, when they have needed things done. But now we are starting up Colliberty properly and will for the first time actively start looking for new customers. Colliberty will be doing web applications, and we’ll do them in Python. We’ll also help you with porting your applications to Python 3, and we will do Python and Plone training, in collaboration with Webworks. At the same time the arrival of my first child, Elenor, has meant that I need to move. My lovely Parisian penthouse just isn’t big enough anymore. And getting a nice and big apartment in Paris is as I’m sure you can imagine, quite expensive. So we decided to move elsewhere. And when looking at different places both around France and around the world, one place quickly stood out: Kraków, Poland! Polands economy is buzzing and expanding, and the laws are business friendly; Kraków is a beautiful, historic town not to far from to Elenors grand parents. It combines family, interests and business opportunities for me. Kraków even has a Python Users Group! So later this year we are moving to Kraków! This may seem like a big change, and for my personal life it of course is. But when it comes to business, it isn’t. After all, I don’t have any regular customers in Paris anyway. In todays globalized world, it makes little difference if the customer is a hundred miles away or thousands of miles away. I’ll miss Paris, and I’ll miss seeing the Eiffel tower in the mornings, but it will be business as usual, with meetings online and conferences on the other side of the world. Filed under: plone, python, zope [Less]