At the time of this writing, this is the farthest I've gotten with this experiment in Zope 3. What this file, browser.zcml does is wire up some basic views for the Todo List and Todo items. At this point, we have not written any HTML templates or any view controllers. At this stage, we don't really need to. This is all that is needed to use automatic add and edit forms, complete with code validation. The interfaces we defined go a long way to providing these forms with their display. We also define some containerViews for the Todo List. Since the TodoList subclasses and sub-interfaces a standard Zope 3 container implementation (think 'Folder', but much simpler. More like a dictionary), it would be nice to reuse the basic container views for the Todo List. This is how we'll get away with adding Todo items:
<configure xmlns="http://namespaces.zope.org/browser">
<!-- Allow adding of the Todo List -->
<addMenuItem
class="todo.TodoList"
title="Todo List"
description="A Todo List"
permission="zope.ManageContent"
/>
<!-- Allow basic Zope 3 container views for the Todo List -->
<containerViews
for=".interfaces.ITodoList"
index="zope.View"
contents="zope.View"
add="zope.ManageContent"
/>
<!-- And now add / edit forms for the Todo list -->
<addform
label="Add Todo"
name="addtodo.html"
schema="todo.interfaces.ITodo"
content_factory="todo.Todo"
permission="zope.ManageContent"
/>
<addMenuItem
class="todo.Todo"
title="Todo"
description="A Todo Item"
permission="zope.ManageContent"
view="addtodo.html"
/>
<editform
schema="todo.interfaces.ITodo"
for="todo.interfaces.ITodo"
label="Edit Todo"
name="edit.html"
permission="zope.ManageContent"
menu="zmi_views" title="Edit"
/>
</configure>
There is more that these ZCML declarations can do - filter out specific fields from a Schema definition, wire into custom classes that override widget definitions or provide other help, or use alternate templates than the ones the system uses. This allows the add/edit functionality to be used in custom applications that don't make use of the ZMI but could otherwise benefit by what these editform and addform view controllers provide.
Screen shots of the views generated by these declarations are in the extended entry.
After the basic code and interfaces, comes the trick of wiring the content objects into Zope 3. This is done via ZCML, an extensible configuration language that defines and describes components for use in Zope 3. ZCML may appear to be verbose, and I have not always been its biggest fan, but I have learned that it is almost always better to be explicit than implicit. Zope 2 often made many implicit assumptions. For the most part, this wasn't a problem. But when it was a problem, it was usually something hard to find and debug. When found, it was usually something in the system that was doing something clever and assumptive that the developer didn't expect it to be clever and assumptive about.
So now that our interfaces and content classes are in, it's time to wire them in. Using ZCML, we can define behavior and interfaces for objects outside of code. For example, declaring IAttributeAnnotatable support allows other Zope 3 components to add annotations. Annotations include things like Dublin Core support, which lets Zope 3 track title, description, modified time, etc, without the developer needing to code in support themselves like they did (or inherited) in Zope 2. Much of the security declarations that filled in Zope 2 python based product code is moved to ZCML. Other elements of ZCML might be recognized as similar to the Python code in the Product initialize(context): code:
<configure xmlns="http://namespaces.zope.org/zope">
<interface
interface=".interfaces.ITodoList"
type="zope.app.content.interfaces.IContentType"
/>
<content class="todo.TodoList">
<implements
interface="zope.app.annotation.interfaces.IAttributeAnnotatable"
/>
<implements
interface="zope.app.container.interfaces.IContentContainer"
/>
<factory id="todo.TodoList" description="Todo List"/>
<require
permission="zope.ManageContent"
interface=".interfaces.ITodoList"
/>
</content>
<interface
interface=".interfaces.ITodo"
type="zope.app.content.interfaces.IContentType"
/>
<content class="todo.Todo">
<implements
interface="zope.app.annotation.interfaces.IAttributeAnnotatable"
/>
<implements
interface="zope.app.container.interfaces.IContentContainer"
/>
<factory id="todo.Todo" description="Todo"/>
<require
permission="zope.ManageContent"
interface=".interfaces.ITodo"
/>
<require
permission="zope.ManageContent"
set_schema=".interfaces.ITodo"
/>
</content>
<include file="browser.zcml"/>
</configure>
The last line, include file="browser.zcml", I'll get to shortly. That is where the web interface is wired in. So far in developing this little project, I've only learned and done the basic add and edit forms, which are really easy in Zope 3. This is where the interface schema items will come into play. Similar, I assume, to how Ruby On Rails has Scaffolding.
But what we've done so far is setup the Model objects and wired them into the basic Zope 3 application. Next - standard views and controllers.
A significant design choice of Zope 3 is that it's interface driven. Interfaces are used not only to document, but to adapt. Interfaces are Zope 3's type system. Unlike class based types, anything can implement them or adapt to them, and all proper code in the Zope 3 system should ask for an interface implementation for a given object.
Interface design has been taken beyond basic method definitions to include object schema and even pre / post conditions. This data can be introspected to build user interfaces, which is how much of the standard Zope 3 management interface gets built. In fact, I'll show how this is done next in the series.
So the basic todo application uses the following interfaces. These are just the basic model objects. The Todo List is just a container that only contains items that implement the ITodo interface. A Todo doesn't do much beyond store some simple data. So here they are, from the file 'interfaces.py' in the package 'todo':
from zope.interface import Interface
import zope.schema
# These will aid in making a special "todo" container by specifying the
# constraint in the interface.
from zope.app.container.constraints import ItemTypePrecondition
from zope.app.container.interfaces import IContained, IContainer
class ITodo(Interface):
""" A todo item doesn"t need to do much... """
description = zope.schema.TextLine(
title=u"To Do",
required=True,
)
details = zope.schema.Text(
title=u"Details",
required=False,
)
done = zope.schema.Bool(title=u"Done")
class ITodoList(IContainer):
""" A todo list contains todo objects. """
def __setitem__(name, object):
""" Add an ITodo object. """
__setitem__.precondition = ItemTypePrecondition(ITodo)
The implementation is even simpler. Since this is a small application, I put the implementation in todo/__init__.py:
from zope.interface import implements
from zope.app.container.btree import BTreeContainer
from persistent import Persistent
from interfaces import ITodoList, ITodo
class TodoList(BTreeContainer):
implements(ITodoList)
class Todo(Persistent):
implements(ITodo)
description = u""
details = u""
done = False
And that's it. Really! Now what needs to be done next is to wire these into Zope 3. But already, one can see that this is much simpler than what one might have to do to write some data objects for Zope 2.
Zope 3 is a skinnable system. It comes with a new "Zope Management Interface", but a nice thing about Zope 3 is that you can write an application that uses Zope 3 that does not use nor care for the ZMI at all. Like in Plone and the CMF, Skins are set up in layers, with the ability to override where you might want.
The default skin for Zope X3 is a basic ZMI web interface. It's single screen now, not multi-paned like Zope 2's. But - it uses a javascript based tree for folder navigation. This tree works in Internet Explorer and Mozilla/Firefox, but not in the current release (1.2) of Apple's Safari browser (based oh KHTML). Zope provides an alternative skin, StaticTree for this situation. But I could not find StaticTree mentioned in the Zope 3 developers book. If I hadn't had to deal with this before, I would probably not have found it easily without searching through mailing list archives or the Zope 3 wiki. Fortunately, I did remember it. So I'm recording it here, as it was the first thing I had to do to really get Zope X3 usable "out of the box" for my preferred browser.
How to find out what skins are available: Zope 3 provides an excellent API documentation tool, readily available from the Help option in the new ZMI. From the API Documentation tool, I visited Presentations from the top navigation pane. In the bottom navigation pane was a link that said Show Skins and Layers. Clicking on that brought up a page showing all of the skins that are defined in the system, including which one is configured as the default, and the layers that makes up the skin. It also included references to where each skin and layer is defined - down to the file path and line number. On this page was listed StaticTree.
How to change the default skin: Most Zope setups these days run out of an instance home, basically a local set of files and scripts that runs the Zope app server and contains configuration for that particular running, while the bulk of the Zope system resides in a common location on the file system. Zope 3 uses this as well. In an instance home is the etc/ directory containing configuration files. One of these files that is important to customizing your Zope 3 instance is overrides.zcml. The default overrides.zcml is empty, except for a few comments, including a comment on how to set the default skin. Here's what the inner contents, sans comments, of my etc/overrides.zcml file looks like now:
<browser:defaultSkin name="StaticTree" />
After restarting the Zope 3 web server, I can now see the navigation tree in Safari.
I saw a weblog entry from Titus Brown today talking about Python and Web Frameworks
: It sounds like rewinding the clock by 5 or 10 years and building a leaner, meaner Zope with Python 2.2 would result in the similar advantages for Python: One True App Framework.
In theory, Zope 3 is just that. Without the clock going back five or ten years. Going back ten years, though, you do have just that in Bobo. The Python Object Publisher (ZPublisher in Zope 2, zope.publisher in Zope 3) is at its heart a very simple concept: publishing objects on a URL. I wrote my first Bobo application back in early 1997 and was amazed with how easy it was to take a healthy chunk of existing Python code and put it up on the web. It was much easier than Python CGI programming at the time. There was no grand framework to speak of - just a collection of tools one could mix and match as desired: Bobo for publishing, DTML (a smaller and simpler version of DTML than the one that exists now in Zope) for templating, and BoboPOS for object persistence. In a day, I converted an application that my company had been struggling with from a Java applet front end to a web front end. And half of that day was spent making pretty HTML.
Bobo did a lot of things right that were lacking in almost every other web system of the time, especially plain CGI programming. It's genius was that it was an ORB - an Object Request Broker - that translated HTTP requests and URLs into object calls and traversal. It even included some marshalling features to automatically have values come in as integers, floats, or other value types. My memories of Python CGI programming, which I last did about ten years ago, was that almost all of my time was spent getting data in from the CGI process into the right formats and into an object call, and then back out. I got to spend very little time with my application objects. Bobo turned that around completely. And now in Rails and other application systems like the impressive Seaside and its Ruby equivalient, Wee (which I think is a much more impressive system than Rails), you're seeing similar. But Bobo and BoboPOS did a lot of this stuff back in at least 1996, if not before. And it was on these basic tools that Principia, which became Zope, was built.
So if you rewind the clock ten years, there is a good, powerful, and simple toolkit to build a new system on. Yes - Zope 2 is a complex and strange beast. So what now? Zope 3. Zope 3 right now is actually called Zope X3. It has no backwards compatibility with Zope 2 and is still more of an experimental release. What it is is a complete rewrite of Zope that attempts to deliver the basic tenets of what Bobo offered while also providing a strong application framework that provides even more services. Chief among these services is a strong concept of object adaptation. And, as I wrote up (nearly 2 years ago), aggregation and adaptation is used more than inheritence. Objects aren't expected to know everything. Helper objects can be used or written as needed.
Now, I have not really used Zope 3 very much yet myself. Day to day business work keeps me in Zope 2 land as Zope X3 3.0.0 just barely landed. So after glancing over how to make a simple todo app in Rails, I've decided to try out Zope X3 to do something similar.
First step, installation. I'm running this on my desktop iMac G5, basic Mac OS X 10.3 setup - no MySQL installed or any crap like that. And the nice thing with Zope is that you don't need an RDBMS. Installation required getting an updated Python (the Python in Mac OS X is 2.3.0, and Zope requires 2.3.4), downloading the source release, and then the basic configure; make; make check; install routine. No further bindings needed. (Of course, Zope X3 can work with MySQL and other RDBMS's, but you don't need to). So installation went pretty smooth.
Also, for this, I'm going off of The Zope 3 Developer Book. Yes, virginia, there is documentation! So far, getting Zope 3 up and running has been pretty easy.
I just had a rather pleasant experience with Apple's iMac Support Site. I had an old CDR with a label on it that wouldn't eject. Part of the disk was bad, as one of the folders wouldn't load in the Finder and the Finder itself had to be relaunched to regain control. I ejected the disk and the system unmounted it, but it did not come out of the drive (nor seemed to make any effort to do so). So I visited Apple's iMac support site and opened up the iMac G5 Troubleshooting Assistant. On the starting page of options was "My CD or DVD drive isn't working properly." On the second page was "My disc won't eject." I clicked on that and it walked me through the basics of ejecting a disc (using the Eject key on the keyboard, ejecting from the Finder) with clear pictures of keyboard keys and on-screen visuals to use and look for. But (as I expected) this didn't do the trick, as the system already suspected the CD as having been ejected. And for what it's worth, the Disk Utility application showed nothing for that drive either. So the next page that came up asked if I was on the computer that was having the problem or on a different machine. I told it I was on the computer in question and it brought up a new window with printable instructions for what to do next.
The instructions dealt with going into Open Firmware, the low level booting firmware used by all modern Macs. I'm unsure how daunting this experience might be to users like my parents, but the instructions were very clear. They included a picture of the Mac keyboard with the special boot keys highlighted (command-option-O-F) and instructions on what will be seen. The commands to type in are fairly simple, eject cd and then mac-boot. I tried eject cd and sure enough, the CDR in question ejected quickly and smoothly. For some quick foolish fun, I poked around Open Firmware briefly, ultimately finding the words command which shows all of the words defined to control Open Firmware. Then I typed mac-boot and the startup process resumed as normal.
Overall, it was a very smooth process with no wasted clicks trying to find answers to my question. And if I couldn't find answers, the troubleshooting assistant maintained a "Chat with Apple Support" button at the bottom of the window, and the printable instructions had the URL back to the iMac support site if the open firmware option didn't work.
When I went back to the iMac support site, a JavaScript Window popped up alerting me that it noticed I had been using the TroubleShooting Assistant and had added a link to resume where I had left off, which I thought a was very impressive and nice thing to offer. Curious about what came next, I resumed the assistant. The next page that came up noted that if none of the previous tricks had worked, the drive might need to be replaced with options and descriptions about what to do next - replace the drive manually, take the iMac to an Apple Authorized Service Provider, or take it to a nearby Apple Retail Store. The assistant pushed the manual replacement as an option if the stuck disc wasn't important.
With the iMac G5, Apple seems to be making strides towards user serviceable machines that still fit their stylistic guidelines for consumer machines, at least, with their high end consumer machines. While the iMac G5 is pretty easy to open up and add RAM to, apparently the new stripped-down Mac mini is not. This makes some sense, as with its price the Mac mini is more of a disposable and replaceable machine if it develops too many problems in its life. Keep the display, buy a new cute and tiny CPU. With the all in ones, there's an expectation for them to last longer, at least in my experience. My iMac DV (G3/400) served me fine for many years, but one of the reasons I held on to it was that I knew that upgrading meant replacing the whole system and I wanted that upgrade to be worth it, and that came true with the iMac G5. With all of the things that can potentially go wrong with a computer, especially an all-in-one unit, over its lifetime, it makes sense for Apple to make the architecture easier for end users to support. It's not the DIY build-your-own-box that many geeks seem to prefer, but it's better than the more rigid architectures demanded by the styling of the iMac G3 and G4 systems (although Apple did a nice job with the iMac G3 DV (slot loading optical drive) systems, making the RAM and Airport card slots fairly accessible).
How this works out in the long run has yet to be seen. But there is a different feel coming from Apple these days. Maybe it's the new strength of the brand, courtesy of the iPod, iTunes, the iBook, and the iMac G5. Maybe it's the communication Apple is getting directly with customers through their successful retail operations. Maybe it's the growing media attention with lines like "hey, I can browse the web on this machine too, and not have to deal with all the viruses currently affecting the Windows world, and it's pretty darn easy to use and good looking too," that's bringing more "switchers" in. Maybe it's that The New Apple (second coming of Steve Jobs Apple) has been around long enough with enough successes and failures (iMac versus Cube) to know what works and what doesn't. Maybe it's just a new sense of pride (part of the strength of the brand) that comes from all of the above. Whatever it is, there is a rather positive feel. Or maybe I'm just feeling a buzz from my pleasant little "oops, how do I get a busted CD out?" support experience. In any case, I'm even happier with this machine and company that I've been a fan of so long. It's experiences like this that enhance brand loyalty, even more than the sexiness of the hardware/software.
Compare and Contrast: Rathergate vs. WMD. A fun filled table comparing the story of nothing and the story of true merit. This is especially fun because now the search for Saddam's Weapons of Mass Destruction has officially ended.
WASHINGTON - The White House acknowledged Wednesday that its hunt for Iraqi weapons of mass destruction — a two-year search costing millions of dollars — has closed down without finding the stockpiles that President Bush cited as a justification for overthrowing Saddam Hussein.So again: the United States rushes to war with one of its main claims based on bad information from questionable sources, and CBS rushes to air with a story about the president based on information from questionable sources. Now - one of these stories told (each based on bad document and sources) has proven to be completely false. And it's not the one that's led to the deaths of over a thousand American servicemen and tens of thousands of innocent Iraqi civilians.
So when do the fired CBS employees get their Presidential Medals of Honor?
Terry Jones: Of course it's wonderful to see the human race rallying to the aid of [Asian tsunami] disaster victims, but it's the inconsistency that has me foxed. Nobody is making this sort of fuss about all the people killed in Iraq, and yet it's a human catastrophe of comparable dimensions.
(Read more...)
There are a lot of great quotes, notes, and lines in this article. I'm not going to quote them all, as much as I would like to. Iraqi lives are being aggressively and negatively affected by the war in Iraq, whether by insurgents or "coalition" forces. Wars are ruining lives all over the world (especially in Africa), yet they go ignored (especially if they're in Africa) by most of the world. And while it is great to see so much rallying to the aid of natural disaster victims, the treatment of man's worst disaster on man (war) is touched on ever so briefly, and always downplayed in the media. But hey - Jennifer Aniston and Brad Pitt broke up! Where should I go to send Brad some support money and Jen some support cuddling?
Of course, Terry Jones is an actor, director, and member of Monty Python. And British. Being an actor, and a foreign one at that, he should just stay out of politics like all people in Hollywood. Unless those people are Arnold Schwarzenegger, Ronald Reagan, etc.
Via Eschaton: The funny (and of course overlooked by the cranial-rectal inversion crowd) thing about the CBS/document story is that contrary to the screeching about it, the entire saga is proof that there is no goddamn liberal media.
(Read More...)
Excellent post from Atrios concerning the amount of real bullshit that goes on in the media today and in recent years and the comparative actions. From Jayson Blair and Stephen Glass to all of the crap that was Whitewater-era trash journalism. I do not understand how this country keeps itself so easily involved with every little fake crisis that the media or this current administration can come up with while ignoring real issues, or quietly forgetting similar situations that don't shine favorably on The Right.
A boob gets exposed during half time at the Superbowl last year, and we get "nipplegate." CBS rushes a story with cooked documents from questionable sources and we get "Rathergate." George Tenet and the CIA aid a spurious war in Iraq by rushing cooked documents from questionable sources, thousands die, and Tenet gets a presidential medal of freedom and Bush gets re-elected. And where's the *gate on this talk show host that turned himself into a paid advertisement for Bush's No Child Left Behind act? Or is that one going to quietly disappear while this whole Dan Rather thing goes on for eight months, or however long it takes until the Robert Blake murder trial kicks into high gear so we can talk about that non-stop?
I do not, do not, do not, do not understand the appeal of Podcasting. Why one would want to do it, and why one would want to listen. Are geeks really this needy for whatever weird little fame and self importance they can get? Some bloggers are boring enough to read, Checked in at Hotel, walked on the beach, lovely day
. I don't need to hear them saying this.
Especially if Podcasting gets to be like weblogging. I could not (and still can not) stand the whole blogging-versus-traditional-media meme. "Bla bla bla's not paying enough attention to blogs" "bla bla bla didn't credit me for being the genius that I am and coming up with putting words on the internet" "bla bla bla wouldn't have happened if all big media were like a blog" "bloggers do it with their keys on." Now are we going to have all of these people talking about it too?
Now that video phones are taking off, and bandwidth and compression both continue to improve, how much longer do we have until every self important geek is making "vidcasts" about how much better they are than traditional media?
The cults of fame and personality are inverting.