Jinja2 in zope

Getting Django Tempates inside of zope is not trivial. Yet getting Jinja2 to run inside of zope is easy! Use easy_install (or whatever) to fetch Jinja2 from PyPi and then from the zope debug shell:

>>> from jinja2 import Template
>>> t = Template('{{ name }} rocks!')
>>> t.render(name='Guido')
u'Guido rocks!'

So what does this mean?

It means that right now you can have Django style templates inside of Plone, Zope, Grok, et al. However, you can't mix TAL and Jinja2 in any way via template inheritence.

Off the top of my head I can think of two possible use cases:

1. You have the HATE for XML based template languages and just need something else for all rendering of all content including HTML. This is actually a very feasible option for Grok and pure Zope application development, yet functionally impossible for Plone. Too much of Plone is woven into TAL to make this work.
2. You are using lots of AJAX via KSS, JQuery, YUI, plain old JavaScript, etc and want something handy to help you write content coming from the server side. This is feasible in Zope, Grok, and even Plone.

The downside of using Jinja2 is that you are adding more complexity to the mix. I like simplicity. I would be very careful about using Jinja2 in Zope products, and would only consider option #2.

Thanks to the the indomitable Ian Bicking for suggesting Jinja2.

Thoughts on Python interfaces

Python does not have interfaces. Yet people have implemented interfaces in Python via some really innovative code (PEAK and Zope 3 comes to mind, but Trac also has them). Those people have great arguments for interfaces, claiming documentation and enhancement of system structure. From what I gather the theory is that if you use interfaces its easy to create truly componentized architectures because you know what to expect from a component.

Now that said, I find it really amusing how often interfaces end up being just so much boilerplate. By this, I mean an empty, (or marker), interface. We are given to understand that one can do so much more, but sometimes a framework demands an interface in a particular place, and often that interface is just plain empty.

I've never played with PEAK elements beyond easy_install. I've toyed with the innards of Trac and been shocked by what makes up the core of that so important software tool. Zope 3 is weel organized and I've done some shockingly fun stuff there after I got over the Zope 3 ZCML hump. And in all of that, I barely saw the need for interfaces. So often I wonder if interfaces are needed.

Well, upon reflection for those systems interfaces work surprising well. The underlying code for Trac might be questionable but anyone can make a plugin by following rules obviously managed by the interface system. Zope 3 is really nice once you get past the curve because you can make components and tie them easily in knots with ZCML (or with python in the case of Grok).

The point of these thoughts? Nothing really. I can live with or without interfaces, and use them in the frameworks that need them.

Me Grok generate Add and Edit forms!

So the first bit of documentation in the grok docs didn't work. Grok has evolved a lot so this is understandable. My thought when I dropped the effort in frustration was that my knowing of where the URLs for the add and edit forms were off. Since the docs I was first working on lacked the URL of what I where I was supposed to go that answer seemed to make sense.

My co-worker suggested I go to the explicit name of the view, which in the Zope 3 world is '@@' this or that. A good suggestion but that didn't work. More on that in a bit.

Examining the Developer Notes I discovered that the docs I was using were out of date. I changed my code to fit the notes, pointed Firefox at the URL named after the form classes, and it just plain worked. Code changes were minimal. And I'm posting to the Grok folks that the form docs are out of date.

Anyway, you can go to /myview or /@@myview in Grok. Which is good. For some reasons that others explain quite well, Zope 3 has this whole big thing with '@@' and '++' in URL bars to explicitly name views, adapters, utilities, oversized SUVs, bad American food, et al. I'm sure some people can't live without them but honestly since Grok avoids them it makes things feel more... pythonic.

Anyway, the add & edit forms, now that I can make them work, are wonderful. Pretty HTML forms with validation done in moments off a little python code.

Me Grok Smash!

So as I started on yet another graphviz application for the web, I decided to go with a new framework. I would use Grok!

Grok comes out of the Zope community, and has its foundation in the rather mature components of that application server. The difference is that tying bits of Grok together does not rely on seemingly arcane xml files. You just code in Python and a bit of TAL for the views. If you want you can leverage in more bits from the Zope world, such as zope.formlib and other interesting bits.

It is a matter of public record that I have a like/hate relationship with zope.formlib.

There are some really nice things I discovered about Grok:

• Intuitive.
• Only one magic bit, in that class defined as views look for their lowercase template automatically, and you can override this if you like.
• The framework is out of the way.
• Inheriting models is a cinch.
• Lets you play with either the ZODB or SQL ORMs.
• Easy use of TAL.

Some negatives:

• A possible gotcha when you instantiate an object inside another object requires you to do a super(MyObject, self).__init__() inside the object's __init__. Not sure why I should have to write this out and it might be I did something wrong.
• Um... still trying to find faults.

I'm rather pleased. Grok has grown up lots since I really looked at it in late autumn of 2007. I look forward to working with it more.

Beware Documentation By Topic

Yes, I know its supposed to be 'Browse', but while looking up some documentation and being distracted I took 'Browse' as 'Beware'. Since it was Grok I immediately thought of rampaging cavemen.

Heh. Fridays...

Should I write a book?

I could be writing a technical booklet of sorts that might grow into a full technical text. Maybe for Plone 3, Zope 3, Grok, or Django. I think I would really prefer writing something for Django. Some concerns:

• Time. Where would I find it?
• Is the pay worth my effort?

Some alleviations to my concerns:

• My consulting has been going slowly. Time could come from there.
• Writing a book would get me more and better work thanks to recognition

What I want in a feed aggregator

The list is simple:

1. One page that displays all the content. Maybe do some pagination, or hide descriptions and just show titles. Otherwise have tags, author, description, and link to original post.
   
2. One page with a text area that accepts one feed per line.
3. Include some sort of authentication.

Ways to get this done
Google App Engine handles #3 for me nicely and gives me free hosting. But feedparser doesn't play well with it and I'm not about to do that kind of debugging. Maybe I ought to try BeautifulSoup?

I'm tempted to try a pure Django system, since that could handle all three, but then I would have to pay for hosting. The same would go for Grok as well. I don't want to pay for hosting yet. Or maybe I ought to just pony up a few bucks a month anyhow...

Of course, I can always write my own simple wxPython client.

What to do... what to do...

Update: Never code on two hours sleep. I'm going with Google app Engine because I realized that when you import of feedparser you can't do this:

import feedparser.py

New Grok site!

http://grok.zope.org/

Much better!

How fast can I convert a Zope 3 app to Grok?

Figured it would be quick and easy to make a conversion. I'm still new with both frameworks, but since Grok is built doing DRY and KISS and various Ruby/Django-isms, this should be pretty easy.

The application in question is a Zope 3 Captcha server that I wrote. It served as my learning box for doing Zope 3 and got me past most of the Zope 3 hump.

I grok Zope 3!

I've struggled with Zope 3 for a bit. I read books, perused documentation, and took a class in Italy. And yet, it felt confusing. Well, this week I had to finish up a Zope 3 solution in record time. So I really hit the books and squinted my eyes real hard. It was frustrating because I got the individual bits, but putting them together was painful and a matter of trial and error rather than an understanding of how to meld components together.

The long and the short is that I used a mix of using Grok and writing Zope 3 tests to figure out problems I was having in my efforts. And then after about two days of struggling and banging my head against the wall, something clicked.

I get Zope 3.

I made something not working work in minutes.

I'm no expert. I've got a long way to go. I've got to work more with Adapters. But tying pieces together is no longer something scary. It makes sense now.

So, here are my lessons learned for anyone who wants to do Zope 3 and is a newbie..

1. Start with Grok. It removes a lot of the overhead and tells you the core bits of how Zope 3 components and interfaces work.

2. Write Zope 3 unit (doc) tests. I can't understate this issue. Don't worry about functional tests. The nice thing is that they insure that before you go to trying to put pieces together, that your component level bugs are mostly gone, so you don't think that zcml is a monster when really its a bug you didn't spot.