How not to build a view
This was originally posted on blogger here.
I like simple, sweet, and easy to use. Which means sometimes Zope 3 style things are awesome, and other times it sucks. What's worse is implementations you have to maintain where someone took something very simple and made it very complex.
In our case study, lets see what a predecessor to me did using Plone and a lot of Five:
- Extended the ATEvent type.
- Created a view using portal_catalog. This creates an object which calls another object which calls a specific function to grab relevant data from each brain object and place that data in a dictionary.
- Made the view, 2 objects and functions bolded above not as extensions as other bits that existed elsewhere but coded them individually.
- Tied it together with zcml.
The end result was a results object containing brains and a counter. Um... okay. I understand this was done so that the Plone template serving this would have the batch features and all, but this is over engineering.
I think a better solution would have been this:
- Extend the ATEvent type.
- Create a utility package with code to be reused in creating batches later.
- Make the view call the utility package so you don't have to code much.
- Tie it together with zcml.
I like this method. The better developers I work with and the gurus I admire will tell you any time you write the same section of code more than once you should look at code reuse techniques. Either wrap your code in functions, use inheritence, or play with polymorphism. All that good stuff.
At least I get paid to maintain this code. Finally it isn't in the NASA effort.
Tags: plone python zope five legacy-blogger