Skip to content. | Skip to navigation

Personal tools

>>> ''.join(word[:3].lower() for word in 'David Isaac Glick'.split())

‘davisagli’

Navigation

You are here: Home

David Glick – Plone developer

by admin posted Apr 05, 2010 11:48 PM

Forcing TAL to render mismatched tags

by David Glick posted Nov 11, 2008 02:39 PM

Today I installed Google website optimizer for a Plone site. This tool requires the use of a </noscript> tag in order to designate the end of a block that may be used in experiments. Unfortunately, if you try to insert this in a Zope page template you'll see something like this:

Compilation failed
zope.tal.htmltalparser.NestingError: No tags are open to match </noscript>, at line 2, column 1

You can work around this using the following idiom:

<tal:block tal:content="structure string:&amp;lt;/noscript&amp;gt;"/>

This bypasses TAL compilation by parsing the </noscript> as a string, then inserts it into the template as HTML structure. The angle brackets are written as HTML entities so that the template has a chance of passing XML validation.

Credit to Darryl Dixon via #plone on IRC, and my colleague Jon Baldivieso for the HTML entities suggestion. Thanks!

3 comments

on the Plone community

by David Glick posted Nov 06, 2008 03:00 PM

Some of you already know that during the past year, I have become quite involved with an open-source software product called Plone. Plone is a content management system--a tool for organizing, presenting, and sharing information on the web. We use it extensively for the websites we build at ONE/Northwest. But more than just a piece of software, Plone is an international community, the people who create the software and build websites with it and support it and promote it.

This Friday has been declared World Plone Day, and in honor of it I want to name some of the traits that I so much appreciate about this worldwide group of people that is Plone:

 

  1. We welcome and empower newcomers. As a complex and powerful system, Plone can seem inscrutable to the newcomer. But there are patient and friendly folks waiting in the Plone forums and IRC channel. I am amazed at the patience and generosity of experienced Plonistas in sharing their hard-earned wisdom. You may not be given all the answers, but if you ask politely you will at least be given the right questions and pointed in the right direction.

     

  2. I'll say again what's been said before: Plone is a do-ocracy. We honor competence, not celebrity. Many open-source projects have a "benevolent dictator for life" or a small cadre of experienced developers who have commit rights. Plone has neither--in fact, the Plone code repository has had 277 direct contributors. And yet somehow, in an ongoing tension between chaos and order, good things keep happening. An important part of this is the care that those in the (nebulous) "inner circle" of Plone take to encourage those on the outskirts who have shown prime talent to step up and take a more active role.

     

  3. We respect each other. This is an unusual thing in an online community, which can tend to be volatile and prone to flame wars. But I have a very keen sense that Plone people value each other as first as people with common interests, before we pay attention to ideology of software design, politics, or other matters. No doubt it helps that we are a relatively small community and have been able to nurture relationships in person at sprints and conferences. But the dividends are great, because respecting those with whom we differ strengthens us via an ongoing interchange of ideas, and we should try to hold this intact even as we grow.

     

  4. We share. Of course we do -- it's hard to quantify our own benefit from the community's past efforts on this software, and we try to give back. Individual developers tidy up code from one-off projects for use by the broader community. Some organizations using Plone have devoted 10 percent of their time to work on the system. Zope's component architecture and the recent push to release packages as Python eggs have put Plone developers in a favorable position by making it easier to release reusable add-on products that don't require invasive changes to the framework, as in so many other platforms.

     

  5. We recognize our limits. Plone is not the right tool for every project. To put it more positively, we focus on a subset of the opportunities that are out there in the world of web development, and try to handle them well. I've been impressed with the candor at which we acknowledge our weaknesses and try to make sure that people are using the correct approach.

     

  6. We don't shy away from hard problems. While we have limitations, we're not afraid of (controlled) experimentation and change to try to remove them. The community benefits both from many years of hard-earned experience and from the enthusiastic contributions of new arrivals. Several versions ago Plone did not use Archetypes or the Zope component architecture, elements which are integral these days. Today, the very orderly progression of minor Plone 3 releases expertly managed by Wichert Akkerman belies a lot of exciting work being done on projects like dexterity, deliverance, contentmirror, repoze.bfg, and a vastly more flexible layout model, whose concepts if not code will likely play some part in what we do in Plone 4. The challenge -- make Plone easier to use for end users, administrators, integrators, deployers, and developers while also making its code leaner and faster -- is not a small one, but (throwing naivet?? to the wind here) if there's any open source project with the community to pull this off, it is Plone.

To the Plonistas: It has been an honor and a privilege to join your ranks and give back in some small ways. Here's to many more thriving years ahead!

1 comment
David Glick

David Glick

I am a problem solver trying to make websites easier to build.

Currently I do this in my spare time as a member of the Plone core team, and during the day as an independent web developer specializing in Plone and custom Python web applications.