Log in



I'm back in Seattle for a while and working for the company that I used to work for.  There are a couple of things that took me by surprise getting back into the codebase.  Most of these are about the saying/idea/adage/whatever that says that code is good when you can come back after 6 months and still understand it.

Well, I'm back after about 9 months and had little trouble understanding most of the code.  The largest hurdle was getting my system setup to run the software, but even that wasn't too bad.  I had to do a couple things that were not quite documented (and I updated the docs to reflect that), but for the most part I could just do what the things said.

The code itself is not as bad as everyone thought when I was here.  Looking at it now, it is actually pretty good.  The nice thing that I learned is that the unit tests that go with the code are some of the most useful things that there are.  And since the code here has such good coverage, I have really had very few problems understanding everything.  Even the poorly written tests are very useful!  I did notice that with the fresh perspective, I could more easily seperate the good from the bad and mediocre.

I even got a chance to try out some new techniques for Template Toolkit!  One problem that we had had, was the when modularizing a template and creating BLOCKs and seperating things out for reuse and using PROCESS to bring them in, you began to have problems with Javascript and CSS that those parts require. 

A simple solution is to place all of that CSS/JS into a main CSS/JS file for the site.  That will work, but then that CSS/JS file starts to get unwieldy and adds quite a bit of unneeded overhead to most pages.  Most of the older templates did it by simply ignoring the HTML standards and putting script, link and style tags all over the place.  That isn't ideal because it means that you are not really future proof for browsers.

I figured out (and this has probably already been done and documented somewhere) that you can use TT's crazy scoping to an advantage.  The part of the template that will print out the head section of the page is put into a WRAPPER.  It expects some variables to possibly contain  an array some extra CSS/JS/what-have-you.  When it prints the head it just loops over the array putting them into the style block with any other CSS/etc.  The other templates can then just push things onto the variable to get their own elements into the head.  Since the WRAPPER code runs after its contents this will work to get all of the content's code into head, and since variables end up being essentially global all of the time (except if you use INCLUDE, I think), they can communicate effectively this way.



December 2007

Powered by LiveJournal.com