The TurboGears team is proud to present TurboGears 2.1.  2.1 has been in development for about one year with the first alpha released in October of 2009.  If you haven’t been following along, here is a review of the changes that 2.1 brings from 2.0.

• Better performance.  The TG team worked hard profiling to see what could be done to make TG faster.  2.1 is at least 20% faster than 2.0 on page-loads as a result.
• Better Mako support.  (quickstart template now includes a –mako option) If you want a highly performant website, Mako is a better option than genshi.
• Kajiki support.  This template engine is for those who like the XML templating on Genshi, but need much better performance.
• Re-written dispatcher.  Object Dispatch has now become Abstract Dispatch, and the code that decides which controller method should be executed has been refactored and consolidated.  An open API is provided for those that want to create their own dispatch mechanisms by using the _dispatch method in your controllers.
• Pylons 1.0 support.  Those of you still running 0.9.7 can do so as well.  TG 2.1 is cross -compatible, which means if you have a 2.0 application, you needn’t upgrade to Pylons 1.0 until you decide to.
• Reduced dependencies. For those of you who use TG as a service, or do not need database or an admin, TG has reduced it’s dependencies to the low-20s.  The full stack with SQLAlchemy and an admin still has about 40 packages, but the packages which were most difficult to install have been removed (those requiring RuleDispatch in particular).
• Finally, documentation improvements.  The documentation has been visually overhauled, reorganized, and brought up to date.  There is still considerable work to do in this area, but a significant effort has been made to solidify those areas which are most often asked about by our users.

TurboGears is committed to maintaining the 2.x branch for the long-term.  This release is intended not to make significant strides in capability, rather to refine our existing functionality in order to add significant consistency to the codebase.  We have already started working on a 2.2 branch, which continues this effort, and will open up more APIs to the framework.  We look forward to your continued support!

A few weeks ago the Front Range Pythoneers decided to organize an “Uncon” where people show up to discuss various topics on-the-spot.  This is the sort of event I really enjoy participating in, so I of course agreed to attend.  At the same time, I was approached by the guys from Developer Day to do a talk on TurboGears.  You can imagine the conundrum I faced, but thanks to the willingness of the DD organizers to be flexible, and some creative planning, I was able to participate in both.

Speaking at Developer Day was a new experience for me because I was talking to folks that were not necessarily versed in Python,never-mind TurboGears.  The conference appeared to be somewhat Rails heavy, but it was refreshing to see organizers reaching out to the greater web community to provide a well rounded conference.  The nice thing about speaking to a wider audience was that I was able to expound some of the history of the Python web, as well as describe TurboGears at a high level without worrying about boring the audience.  I was quite nervous speaking at first, because I have not done so in a few months, but seemed to settle into a groove by the time I showed an example of how easy it is to inject repoze.profile into a TG application and provide a cachegrind display to find any slowdowns in your app.  I hope that this example was able to express how versatile WSGI is.

I stayed the morning at DevDay and I am glad that I did.  Chad Fowler gave an address on what it means to remain passionate as a developer over the life of your career.  I think his idea that providing structure to your life definitely allows you to achieve amazing things.  His real-life examples were poignant and well received.  I’ll be checking out his book soon.  The other talk that I found interesting was Jeremy Hinegardner’s talk which basically discussed the numerous non-relational persistence methods available.  I thought his method for showing examples of the different methods was great. For each one he had a simple succinct example that showed the  benefits for the given persistence framework.  He allowed the audience to choose from the frameworks he discussed in his talk.  Jeremy was an engaging speaker, and I would not hesitate to sit in on one of his talks in the future.

After a bit of DD-provided BeauJos, I headed over to the UnCon.  They too were having pizza provided by Google.  Google Boulder was a great sized venue for the 40 people that attended.  It was exciting to see so many new faces in attendance.  It seemed to me that the “regulars” were doing a lot of demoing, while the new folks watched on, but there was also a lot of discussion that happened.  I showed how to use repoze.profile and runsnakerun to

analyze the results.   Zooko immediately installed runsnakerun and tried it on his app.  It is always nice to have immediate gratification for having taught someone something, even more so when the person voluntarily tries what you think is “so cool.”  I got to show off some of the work I am doing for www.getmvp.com, since much of it is prototypical of the Extension Solution that I hope to provide with a combination of Pylons and TG.  Also on display was TW2.  It was great to show how simply one could express all MVC elements of a widget in one complete package.

Sunday I ran the first TurboGears WorkShop.  If you follow my blog, you may have read a few posts about how I think we can improve sprinting, but I’ve come to the realization that our less-than-stellar sprint performance is really due to a need for improvement in the organization at large.  I have decided to add a WorkShop Series to our tireless effort for improvement of TurboGears, both from a technical aspect, and one of the community.  I was up late on Wednesday creating a basic tutorial-type plan for Sunday, and I finished up with about 80 pages of documentation to provide workshop goers, basically by selecting items from the TurboGears documentation.  My goal for the sprint was to provide sprinters with a working example of TG at the end of the day, with a little bit of work accomplished customizing the Admin.  I asked sprinters to bring their own databases, to utilize sqlautocode as an example database for their new application, and while no one provided the class with one, we were still able to succeed with one that I provided as a backup.  5/6 people succeeded in this, and while there were some rough edges, I think I have an idea that is workable for a 3-6 hour WorkShop that will succeed with a little bit of polish.

I am still formulating the ideas for TurboGears workshops.  I have started to contact folks I know throughout the country, in order to provide venues for these workshops.  So far I have Boston, Dallas, San Fancisco, Atlanta, and Boulder (Denver) lined up.  I think with little effort, I could also add Ann Arbor, and probably Washington D.C.  The idea behind a workshop is that you arrive with a varying amount of knowledge in TG, and you leave with a greater knowledge than you arrived with.  You are encouraged to bring an existing project to hack upon, or to create a new one that we can play with.  I will provide a rough outline of what we might do in the tutorial, but if the group decides to go off in a different direction, that’s okay too.  If you are interested in participating in one of these WorkShops as a mentor, or providing venue space, accommodations, etc. I would love to hear from you.  Right now I am in the organization phase, expect a blog post announcing the official plan in the near future.

Thanks!  Without the efforts of a number of individuals this weekend would have been much less successful than it actually was.  I want to thank Ben Scofield for inviting me to talk at developer day, and for shuffling the schedule so I could participate in both conferences.  Greg Holling put in a great effort to organize the Uncon, and Google provided an awesome venue for us to use.  Three volunteers from Google Boulder provided their time, and even gave a tour of the facility to conference goers.  They weren’t even Python developers…  Jim Baker and Matt Boersma both showed up to provide access to Bivio so that we could have our first-ever TG WorkShop.  Lastly, I’d like to thank Bruce Eckel for making the trip down from the mountains to provide his unique perspective.

Well, it’s been longer than I wanted since the last release.  (almost 4 months)  I was holding out because I wanted to get a few more features working, but I realized this week that there was a lot of new functionality, and so it was time to cut a new release.  It turns out, the codebase grew by almost 20% with this release.  I see this as a very stable release because I use almost every new feature at my day job.  Here’s a rundown on what is new.

* TableFiller can provide field_methods for customization of output.
* You can now customize the query TableFiller uses.
* TableBase now has __xml_field__ modifier that un-escapes the data provided by the given list of fields.
* There is a new tutorial for TableFiller: www.sprox.org/tutorials/table.html .
* Sqashed #8: Synonym Properties causing Tracebacks.
* Added Mako Templates for every sprox widget. (SPEED!)
* Fixed the way relation form fields render.
* Brandon Rhodes provided a fix for TableBase that allows fields to render with any Widget type.
* Teajay Bernard provided *experimental* support for Editable Dojo Grid.
* Test framework fixed to be more forgiving of XML.
* Declarative Validation overrides now work properly.
* Field Class added so that you may override both the Widget _and_ a Validator for a field (documentation pending).

Special thanks to Brandon Rhodes and Teajay Bernard for their contributions.

You can get sprox from pypi at: pypi.python.org/packages/source/s/sprox/sprox-0.6.1.tar.gz

It felt like this year Pycon was executed to near perfection. Many struggles I had with last years Pycon were addressed both by the organizers, and some creative thinking.
In this post I will recap everything that happened from my perspective.

WSGI House

I gathered a few close friends from the TG team and a couple of wildcards for perspective to share a house for the continuum of the conference.  Having a house gave us a place to go home to at night and meet with friends, often staying up late talking about issues surrounding our favorite software.  Having a focused group I feel is important because you spend less time off on wild tangents.  The first (and pretty much only) rule of the house was that you pay the same amount whether you stay one night or nine.  At least one of our members was encouraged by this rule to stay for the sprints which he hadn’t done before. Success!

Tutorials

For me, tutorials got off to a shaky start, but we seemed to recover nicely.  TurboGears has a lot of momentum right now, and it makes it hard to come up with a succinct tutorial when there is so much functionality to cover.  I think we were able to recover and that our students managed to soak in enough knowledge from our proverbial fire hose to create some useful applications.  I think we have a good start on a new book.

I was extremely impressed with the quality of students who were attending my ToscaWidgets tutorial.  Every single student finished every example.  I chose Pylons to give the tutorial, and although it is a little harder to integrate TW in the stream than does TurboGears2, it installed quickly and flawlessly.  Overall, I think the tutorial was a success.

Talks

This year I did not focus on attending the talks, but instead chose wisely based on speaker and topic and allowed my feet to do the walking if the talk became uninteresting.  I definitely missed some talks, but the AV team has done an incredible job putting the talks up on blip.tv so that I can review them later.

This year I did not miss Raymond Hettinger’s talk on AI in python and was enthralled by a speaker who could successfully put a page of code on the screen and keep my interest.  I showed up to support Philip Jenvey in his talk on Pylons on Jython but was impressed by his ability to provide a succinct example on where Jython really shines.  I am hoping that more people take a second look at this really well done presentation.

Now, I am a SQLAlchemy supporter through and through, but find the domain of database mapping an interesting echosystem.  While the ORM panel was littered by advertising chatter from one of the panelists who did not even write an ORM, an obvious dis-inclusion was Robert Brewer who wrote Dejavu, a very nice way to map persistent resources of different types for use in an “objecty” way.  Bob’s talk was especially interesting and makes me wonder if SQLAlchemy could leverage some of the work with AST that Bob beautifully displayed with some of the most amazing one-handed keyboarding I have ever seen.

Open Space

Well, I said I was going to give a talk at the Open Space, and ended up not doing so.  Part of the problem was the utter lack of projectors in the OS rooms, and part of it was a reluctance to break up the collaborative/discussive vibe that was going on in these sessions.  WSGIers hammered out a 2.0 spec, which involved a discussion I only monitored in passing.  I was disappointed by the lack of people who showed up for the GSoC BOF, but I think the economy held back a lot of students from attending Pycon.  It was also nice to allow my feet to walk around and see what was up in different projects.  I met one guy who took REST way to far and got to express some of my dissatisfaction with one of the available tools.  On a more positive note, the TG BOF was well-attended  and it was nice to see so many users wondering what was up in TG land.

Sprints

This year I refused to let the noobs get me down and actually wrote some code.  I am sorry if I did not act as a good host of the TG project, but we have some important milestones coming up and I just wanted to get work done on that.  Sprinting remains a cornerstone of our development process and I will see if we can’t get our monthly
sprints happening again in 2009.  I was however able to completely re-engineer our dispatch system, and while it is not currently 100% complete, it should be finished in a matter of days.  RestController now supports variable arguments for get_one, delete, and put, as well as supporting lookup and default.  Anyone can actually now create their own dispatch mechanism, since this functionality has been generalized.  Simply subclass Dispatcher, override _dispatch() and go to town.  I look forward
to seeing what kind of crazy code this brings to TG land.  A lot of discussion has been had on how to make “plugins” or “extensions” for TG, and you can rest assured that we will have this functionality soon.

Thanks

Thanks to all of my house mates who put up with my “mothering”.  Thanks to all of you who tolerated my “um”s at my talk on Sphinx, and especially to Georg Brandl who answered some questions.  Thanks to the organizers, volunteers and staff that came together to create what has been my best Pycon to date.

So I have had a pretty long hiatus from working on dbsprockets, but I’m back… with a vengeance.  So, I worked hard to get Rum working in TG2, but struggled my ass off and got nowhere.  Left tangled in a web of peak-rules that I did not want to decipher, I began to think about dbsprockets again.  I mean, were we really that far off from what RUM is offering?

The answer turned out to be no.  All I needed to do was to replace the dbsprockets primitives with a class structure.  This turned out to be about an 8 hour job.  Not bad for a day’s work.  And now you can do things like:

from dbsprockets.declaratives import FormBase

from myWebapp.model import User

...

class RegistrationForm(FormBase):
    __model__ = User
    __limit_fields__ = 'user_name', 'email_address', 'display_name', 'password', 'verify'
    __required_fields__ = 'user_name', 'email_address', 'display_name', 'password', 'verify'
    email_address = TextField
    verify = PasswordField('verify')
    __base_validator__ =  Schema(chained_validators=(FieldsMatch('password',
                                                        'verify',
                                                        messages={'invalidNoMatch':
                                                                  "Passwords do not match"}),))
registration_form = RegistrationForm()

class ATurboGearsController(BaseController):
    @validate(form=registration_form.__widget__)
    @expose('genshi:sproxtest.templates.register')
    def register(self, **kw):
        pylons.c.widget = registration_form
        return dict(value={})

This turns out to be a much simpler way of handling forms, because now you can subclass to your heart’s content (for instance, make one base user form which you subclass for admin, registration, profile and login), or even come up with your own wacky WidgetSelector that chooses widgets for you and subclass as you desire. Here is initial documentation, which I will express in more detail at a later date when I have more time to do it the right way.

The simple fact is that you can customize form widgets with ease, limit fields to a set of fields, drop a few fields, basically anything you can think of to change how the database schema actually displays on the page.  The same is true of field validators.  Simply define an attribute of the class that has a validator, widget instance, or widget type, and dbsprockets will do the right thing.  If you want to override both the field and the validator, all you must do is create a widget wit the validator attribute populated.  The greatest thing is that your forms (and tables!) will change with you as your database schema migrates.

Right now I am keeping the primitives way of getting the values from the provider to populate the tables/forms.   This is likely to change in the future.  The primitive way of doing forms is now deprecated.  I will be adding deprecation warnings to the code.  Hooray!

Look for ajax support in the near future on both the view and data side of things.  I have a clear understanding of ExtJS (2.0.1), JSON, and LGPL now and I am not affraid to use it.  In the mean time, a dev version of dbsprockets 0.5 is up at pypi.

Any of you who know me know that I have been struggling with carpal tunnel syndrome for the last year or so.  A combination of working with a laptop in an ergonomically undesirable position, frequent days longer than 12 hours coding, and my personal winter vocation (ice climbing) put me in pretty consistent pain.   The problem with ice climbing is as you reach to place your tool into the ice, your wrist bends at an acute angle.  Then, to move your feet up, you must weight the bent wrists.  The pain got to the point last February where I had to completely stop climbing ice, despite having a trip planned for Ouray.  Even rock climbing had to stop, relegating me to short day trips to the Flat Irons (mostly footwork climbing) until things improved.

The pain lessened long after the ice was melted, and I was able to return to  a pretty regular climbing schedule, but often pressures from my clients would cause the wrist pain to flare up.  I used wrist braces to help keep my wrists in correct position, but I was simply unable to maintain my usual pace without going to bed at night with aching wrists.

With ice season approaching, I had to find a solution to this problem, as I really love climbing ice, it brings you to some pretty spectacular places.  At Plonecon this year, I saw two people with the same unusual keyboard, a Kinesis Advantage.  I asked them about it, and everyone gave it good reviews, saying that it really helped them.  When I got back from Plonecon I plunked down $250 for a refurbished keyboard at home, and started carting it back and forth to work.

This keyboard is not one who’s transition you can t ake lightly.  As you can see, it has an unusual physical layout, but if you have been using a Microsoft Natural Keyboard, the transition may not be too bad.   One think that took a while to get used to is that the keys are aligned vertically.  This creates a lot less strain, but is quite unusal at first. After a month or so of use, I can say that my typing skills have returned to what they once were, even in a programming environment, where you have to use weird symbols, and the arrow keys a lot.

The keyboard has helped me reduce the amount of pain in my wrists enough that I can resume ice climbing.  However, the change comes about not only because the keyboard offers better ergonomics, but it has changed the way I type, equalizing the work that both hands do.  If your keyboard is more than 6, months old, pick it up, and hold it at an angle so you can see which keys have a glossy shine, and which ones are still opaque.  You can learn a lot about a way a person types by examining their keyboard.  Do you use both shift keys?  Which  thumb do you use to hit the spacebar?

The biggest struggle for me with the new keyboard w as the fact that the “b” key is on the left hand.  I’ve been typing that one with the right hand for as long as I can remember.  When I look at how I used to hold my hands over the keyboard, I can see that the left hand is bent a little, which makes hitting the “b” key a little more difficult, which is why I probably did that with the right hand.  Also, I used the left shift key exclusively.  I still struggle with that, but I am getting a better about using the right one as well, you just have to take a little more time when typing capitals to be able to use both.  (This would really suck if I was a JavaProgrammer)

Besides helping improving my typing prowess, the keyboard offloads a lot of work to the thumbs, eliminating the wrist-snapping alt-tab combination that caused the majority of my problems… In fact, ctrl-c, ctrl-v, ctrl-x, where I spend a lot of my time is now a two-handed affair.  This takes a lot of the stress off my left hand, which had much worse pain than the right.  Lastly, the arrow keys are moved to below the left and right hands, and while this is a little weird to get used to, it is nice not having to move my right hand to get to those keys.  It also forces me to use both shift keys more, since you must use them to highlight text the way you need for cutting and pasting.

While the Kinesis keyboard is pretty unusual, and a bit hard to get used to, the keyboard comes with a set of exercises which really helped me get used to it.  The first day, the exercises probably took > 2 hours, but after a week of doing them, I had that down to < 25 minutes.  In between I used my old keyboard, because I just had to get work done, but I used the Kinesis more and more over time, and after a month, it is now full time, and I really don’t like using standard keyboards, but the transition going between the two is not too bad.

This is kind of a long post, but if you are having RSI, and aren’t sure that spending $250+ dollars is going to be worth it, perhaps this blog post will help you decide.   My refurbished keyboard at home is not discernibly different from the brand new one my work purchased for me, and both have worked for a month rock-solid.  The one thing I noticed was that the Kinesis had a somewhat higher energy profile, requiring me to replace my 4 port usb hub with a powered one.  I might add that I had the mouse and old keyboard plugged into the Kinesis, so it was in fact drawing the power of 2 keyboards, if you have the ability to simply replace your old keyboard, you may not see this problem.  Lastly, you are able to re-map the keys on the keyboard, which I did with the up/down keys.  This opens up the posibility for a dvorak layout, but the home keys are different from the other keys, so it might be worth it to invest in the more expensive version that comes with special keys designed specifically for this layout if that is what you prefer.

A few months ago at Ploneconf I met Manabu Terada from Japan who had a 2d barcode on his business card.   This was intriguing to me, and he showed me how his Nokia phone could read in his card, and store his contact information for later use.  Since that time I spent a little bit of time figuring out how my own iPhone could do the same thing, but I had been turned off by the poor image quality the iPhone has, with it’s lack of macro mode.  Well, Grifin has solved that problem.  And Nokia has provided us all with an online version of a barcode generator.  To round out the suite, there is free software available for the iPhone.  So, above you see the barcode for my contact information.  Perhaps you could provide your own barcode with some cheaky message?

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 develo