In the past I have struggled with the fact that some of the OSS code that I write wraps other’s work, creating an evil dependency which is not easily rectified. I am then bound by the wrapee’s software release schedule, as are those who choose to use my software. Yes, I’m talking about ToscaWidgets.I wanted to break free from this paradigm, and I have taken initial steps in my ToscaWidget wrapper for Yahoo YUI. Here comes a huge block of code, but don’t let it scare you, I will explain the problem it intends to solve:
class YUILinkMixin(Link):
params = {'basename': '(string) basename for the given file. if you want yuitest-min.js, the base is yuitest/yuitest',
'suffix': '(string) "", min, beta-min, or beta. Default is "min"',
'version': '(string) select the yui version you would like to use. Default version is: '+__YUI_VERSION__,
'external': '(boolean) default:False True if you would like to grab the file from YAHOO! instead of locally',
'yui_url_base':'The base url for fetching the YUI library externally',
}
version = __YUI_VERSION__
external = __DEFAULT_LINK_IS_EXTERNAL__
yui_url_base = __YUI_URL_BASE__
modname = "tw.yui"
extension = 'js'
default_suffix = __DEFAULT_SUFFIX__
_suffix = ''
def __init__(self, *args, **kw):
super(Link, self).__init__(*args, **kw)
if not self.is_external:
modname = self.modname or self.__module__
self.webdir, self.dirname, self.link = registry.register(
modname, self.filename
)
if 'suffix' in kw:
self.suffix = kw['suffix']
else:
self.suffix = self.default_suffix
def _get_suffix(self):
if self._suffix == '':
return ''
return '-'+self._suffix
def _set_suffix(self, value):
self._suffix = value
suffix = property(_get_suffix, _set_suffix)
@property
def external_link(self):
link = '/'.join((self.yui_url_base, self.version, 'build', self.basename+self.suffix+'.'+self.extension))
#xxx:check for existance of this resource and choose -min -min-beta -debug or no suffix as alternatives.
return link
def _get_link(self):
if self.is_external:
return self.external_link
return tw.framework.url(self._link or '')
def _set_link(self, link):
self._link = link
link = property(_get_link, _set_link)
def abspath(self, filename):
return os.sep.join((os.path.dirname(__file__), filename))
def try_filename(self, filename):
abspath = self.abspath(filename)
if os.path.exists(abspath):
return filename
return False
@property
def filename(self):
#make basename windows/qnix compat
basename = self.basename.replace('/', os.sep)
basename = self.basename.replace('\\', os.sep)
basename = os.sep.join(('static', self.version, 'build', basename))
#try the default
filename = basename+self.suffix+'.'+self.extension
if self.try_filename(filename):
return filename
#try '' if the default suffix is min
if self.default_suffix == '':
filename = basename+self.suffix+'.'+self.extension
if self.try_filename(filename):
return filename
#try min if the default suffix is ''
if self.default_suffix == 'min':
filename = basename+'.'+self.extension
if self.try_filename(filename):
return filename
#try debug
filename = basename+'-debug'+'.'+self.extension
if self.try_filename(filename):
return filename
#try beta-min
filename = basename+'-beta-min'+'.'+self.extension
if self.try_filename(filename):
return filename
#try beta
filename = basename+'-beta'+'.'+self.extension
if self.try_filename(filename):
return filename
#try beta-debug
filename = basename+'-beta-debug'+'.'+self.extension
if self.try_filename(filename):
return filename
return None
@property
def is_external(self):
return self.external
class YUIJSLink(JSLink, YUILinkMixin):
pass
class YUICSSLink(YUILinkMixin, CSSLink):
extension = 'css'
Â
So, the question is, how does using this code differ from using direct links to the YUI library, or using the ubiquitous JSLink Widget provided by ToscaWidgets, which is found in just about every other tw.js_wrapper available?
1) Testabliltiy - First and foremost, I wanted a way to test a new version of the library with my JS code to see if it would work, without having to change the wrapper at all. A bit of a monkey-patch, but if you change the version of YUI that is fetched by altering one variable in the tw.yui library before doing subsequent imports. If the current version is not available in the widget library, you can point it directly at yui's online library. Run your tests, see what breaks, fix it, and you are now compatible with the new library.
2) Debugability - Synchronous with Testability, you can also set a flag for tw.yui to include all of the debug versions of the yui modules so you can dig down into the code using firebug if need be. (The default is minified)
3) Compatibility - Since you now can control what version of YUI you want to use, you can retro-fit an older project with Toscawidgets by downgrading the version of YUI that tw.yui is using. You can also try out the newest version of YUI that may tw.yui is not yet using, and with the exception of new modules that have not been integrated into tw.yui, it should still work.
4) Maintainability - Since we now have the ability to swap versions, the maintainers of tw.yui can keep multiple versions of yui in the library, and deprecate them as they see fit. This provides maintainability, as you would expect to see deprecation warnings about your WSGI Application's use of an out-of-date JS library. This helps the whole process of knowing what libraries are current to what version, which can be a real bear, given all of the things we all must keep track of.
5) Producibility - The bottom line always comes down to whether or not you can pipe your development software up to production level efficiently. (Is the code producible). With the ability to test compatibility, and drop down to different versions of dependent libraries when compatibility is a concern, you will be able to keep all that works on your production server working, while bringing up new or updated functionality incrementally. Keep in mind that the above code demonstrates the ability for system-level defaults of the javascript link widgets to be overridden for any particular widget instantiation.
These 5 items I call Production Engineering. Basically, Production Engineering is developing a process which allows you to integrate working development code into your stead-fast production site, and allow you to back out software which may have mistakes. A good software engineer realizes that people make mistakes, and there needs to be a way to buy some time so those mistakes can be fixed. I believe that YUILinkMixin is a step in this direction, and I hope to extend it in the future to provide an even more robust toolset in line with Production Engineering.The complete source code for tw.yui is available at www.toscawidgets.org/hg .
Tags: Agile Development, JavaScript, Maintainabilty, Production Engineering, Python, Test Driven Development, Testing, toscawidgets, Turbogears, Yahoo, YUI

I besides believe therefore , perfectly composed post! .
Wow, wonderful blog layout! How long have you ever been blogging for? you make blogging look easy. The full glance of your website is fantastic, as well as the content!