| Applying monkey patches in Django middleware layerPosted on August 12, 2010 by Mikko OhtamaaFiled Under django, plone, python, technology Monkey patching is a technique to modify module functions or class methods in Python and other dynamic languages run-time. It differs from the traditional source code patching that it does not need separate utility or compilation process to become effective. This means that you can deploy patches to codebase not under your control with your application without extra effort. Monkey patching has been made famous by Plone/Zope community where there is even collective.monkeypatcher add-on for managed monkey patching. Because monkey patches do not need a compilation stage, the patch will work with the future versions of the application, assuming the patched function or method is not changed. So you can “safely” update the patched software and the patch will apply to the new version without need to go to command-line to perform some cumbersome commands. However, it is the best practice of open source community to report the bugs and submit the fixing patches, as source code patch, in the corresponding issue trackers. In Django context, you can use monkey patching to
Patches are usually applied when Python does module imports. You have a special module called “monkeypatches.py” and when that is imported, it applies the patches when the module body level code runs. However, it is difficult to find stable import point in Django to run monkey patching. Django does some really evil magic to initialize INSTALLED_APPS, database models and stuff and doing any kind of work during import causes headache. So I figured out that you can apply monkey patches using middleware. Middleware applies the monkey patch when the first HTTP request hits the process (note that if you run preforked web server like FCGI every process has its own run-time code in memory). This technique, of course, cannot be used to monkey-patch things that happen before middleware processing, but it is not often needed. Below is an example how to monkey-patch Django CMS to normalize its unicode output. There was an issue with unicode characters and this is a stop-gap measure to fix it. (I think the proper fix would be fix related Cufon font renderin Javascript library). We add our monkey patcher to loaded middleware in settings.py. MIDDLEWARE_CLASSES = (
...
'foobar.middleware.FixCufonUnicodeNormalization',
)
The actual monkey patching happens by fiddling with the class code in process_request(). Note that in this particular case we only need to transform the output of the original function, we can simply hold a reference into it, call it and perform our transformation on the result. This way our monkey patch do not hinder the orignal function and is update safe (it does not matter if the code of PlaceholderNode.render method changes). import unicodedata
# Orignal function we monkey-patched away
_orignal_render = None
def _patched_render(self, context):
""" Normalize all unicode output of Placeholder nodes in Django templates """
content = _orignal_render(self, context)
# http://docs.python.org/library/unicodedata.html
return unicodedata.normalize("NFC", content)
class FixCufonUnicodeNormalization(object):
""" Fix issue with Cufon, user-generated HTML and unicode decomposed characters.
http://github.com/sorccu/cufon/issues/issue/133
"""
def process_request(self, request):
""" Install monkey-patch on demand.
If monkey-patch has not been run in for this process (assuming multiple preforked processes),
then do it now.
"""
from cms.templatetags.cms_tags import PlaceholderNode
global _orignal_render, _patched_render
if not _orignal_render:
# replace one of the class's method with own fixed version
_orignal_render = PlaceholderNode.render
PlaceholderNode.render = _patched_render
As far as I know, monkey patching is something PHP cannot do
Building a mobile site and applications with Django and PythonPosted on September 30, 2009 by Mikko OhtamaaFiled Under Business, django, iphone, linux, mobile, pys60, python, technology Recently we created a mobile site for an interactive bicycle tour. oulugo.mobi (you need to use mobile browser to access the site or you’ll get a redirect) is a multimedia enriched bicycle tour through the historic parts of the city of Oulu. All content is provided by OnGo. The route, which you can bicycle through is drawn on Google Maps. There are nine action points where the user can listen to streaming audio clips, with still images, in his/her mobile phone. This is sort of augmented reality experience: The user sees the real world (where he/she is now bicycling) combined with the historic events (audio playback narrative). For example, at Linnansaari (a location on the route) you’ll see the actual 17th century castle ruins and the narrator tells how the castle exploded when fire, caused by a lighting, reached gunpowder warehouse… boom. The explosion caused stones fly over 400 meters. Alternatively, the clips are available as podcasts from Oulu Tourism pages. You can download them into your iPod for offline listening and use in conjuction with a paper map. This demostrates interesting mix of multichannel publishing: paper, web, mobile and podcasts. The tour is bilingual in Finnish and English. There exists unreleased iPhone application, based on PhoneGap, which allows the user to track his/her location real-time on the web page. We didn’t see it worth of trouble to go through Apple iPhone application review process. When location based service support comes for the browser this feature is indended to be included as the standard HTML5 feature of the service. There also exists Nokia Series 60 mobile application, based on PyS60 and Series 60 BrowserControl API, which allows the user to track his/her location in real-time. The application provides wrapper around Series 60 WebKit control and allows Javascript to access phone native functions (GPS) over localhost socket communication. Like with Apple, we didn’t see real-time tracking feature interesting enough to go through Symbian Signed process to get our application released. Also, BrowserControl had seriousquality problems and we didn’t consider it stable enough for the end users. Some work is available in PyS60 Community Edition repository. The service is hosted on Python specific virtual server on Twinapex services server farm. Features
Software stack
Development effortDevelopment time: Around 100 hours. Three different developers where involved. Used development tools: Eclipse, PyDev, Subclipse, Subversion. There were around five meetings between the content provider and the technology provider. Few beta testing rounds using iPhone application were performed by bicycling in -10 celcius degrees weather (north and so on…). No polar bears were harmed during the creation of this mobile service. The service is linked in from Oulu Tourism pages and thousands of paper brochures printed for Oulu summer season 2009. About the author Mikko Ohtamaa |
Latest Top Shouts | Want to get mobile? |
