So, Pycon registration has been up for a few days, I will be speaking both on and off-podium (read: open space) and providing assistance to and presenting tutorials.  Here is a run down of what I am planning in case you wanted a little bit more in-depth information.

Tutorials:

Turbogears2 Beginner and Intermediate:

I will be assisting Mark Ramm by giving individuals help installing and using the new TurboGears2 framework.  Mark is an experienced tutorial presenter, an expert in the technology, and in general a fun character to spend a few hours with.  When you leave his tutorials you should expect to have a working version of TG2 on your machine, along with an understanding of Model, View, and Controller paradigms.  Middleware, Forms, and REST will also be covered.  One note, if you are getting started with TG2, it’s best to have it installed and running if you plan to attend only the Intermediate Section.  We will not be going over installation in the second-half.

 Toscawidgets: Test Driven Modular Ajax:

I am presenting this tutorial which will describe how to use the valuable Toscawidgets package to create web content.  If you are currently use WSGI technology, and are interested in creating reusable, modular web content, this is a perfect way to get started.  I will show you how to configure TW middleware to work with pylons (which is applicable to other frameworks like repoze.bfg, paste, or even plone/Grok).  I will then describe how you might use this middleware to generate web forms.  The last few hours of class will be devoted to using the JavaScript utilities of TW to create an Ajaxified website, and test it using YUITest.

The Big F’ing Tutorial: Development Using the repoze.bfg Web Framework

I will assist/present with Chris McDonough about this up-and-coming framework who’s goals are to utilize bits of the zope 3 framework, wsgi, and new technologies to make a lighting-fast web server.  Those of you who are familiar with Zope technologies may be interested to find how nicely some of the familiar bits of zope are integrated with wsgi with repoze.bfg.

 Presentations:

Using Sphinx and Doctests to provide Robust Documentation

This is a 1/2 hour slot which describes how you can integrate tested documentation with your source code… with sanity!  I go over a quick install of Sphinx, and use some screencasts to demenstrate how to add, run, and display doctests using it.

Open Space:Agile Development with SQLAlchemy and Python Testing Tools

I really enjoy giving this talk, and even though it was not accepted as a formal talk, I will find a venue by way of Open Space to express my knowledge of Testing, SA, and Nose.  I have given this talk a few times now, and it’s fairly polished.  My presentation, while on some dry topics, won’t put you to sleep.  Carefully prepared screencasts and photograph-punctuated slides makes the 45 minutes breeze by.  Questioneers/Hecklers welcome!

 Sprint Topics

I want to spend some time with the Dispatch of TG2, and probably push Sprox further a bit.  If you are just starting with TG, please feel free to contribute.  Sprinting is a great way to learn a lot from the experts in the domain.  We usually do a meet-greet-install the night before the sprints.  Oh, and I’ve been known to provide refreshments to all of our sprinting hordes (read: FREE BEER).

So, I hope to see all of you there!  If you see me in the hall, feel free to introduce yourself and tell me what you are using Python for!

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 .

My own ideas revolve around DBSprockets and TwTools, which is not surprising since I am the owner of said projects.  The largest project and the one which I have the most desire to see put into action is that of a TurboGears CMS.  There had been some work done last year by the guys at Pagoda which produced a brilliant screencast, but the project seems stalled out and it would be nice to see it revived.  Furthermore, the solution I proposed is intended to be much more modular, so you could pick apart portions of the CMS and put them in your existing applications.  I think this would be the most flexible solution, and also one which would employ much that DBSprockets, TwTools, and Toscawidgets have to offer.  If you are a student who is interested in working on this project, please don’t hesitate to drop me a line.  You can also track me down at Pycon for the remainder of the week, and at the TurboGears sprint next week.  If you are a student who is eager to get started feel free to participate in our sprint, remotely or in person.   

One of the great things I see coming from this mini-project is that we now have a very nice set of concrete ideas about how to make TurboGears better.  Whether or not students participate in the development we still get a huge benefit from the creation of ideas, and it gives the development team and possibly new developers a target to make TurboGears the best it can be.  My hope is that these ideas will not only bring a students to our project, but also bring some developers out of the woodwork who may have started similar projects and would like to contribute.  The bottom line is, if you aren’t a contributor, and want to be, here is a great place to start.