This is old news for many (just you wait for the next entry I am about to post!) but I have to start somewhere.
So the last three weeks have been incredibly busy for two things. You’ll have to wait until my next entry to learn about the second, but the first was Willi and I each initiated our own massive projects at the Berglund Center about four weeks ago. Willi elected to re-design the BCIS Interface on the Internet while I volunteered to re-design the older, more horribly coded JAHC site. Let’s recall that Willi is more of a web designer than a web developer so it was pretty much understood I would be in charge of the underlying technology and content migrations for both re-design projects. Scratch that, for both online journals ranging in age from six to almost ten years running. Both projects were pretty ambitious.
But that’s why we decided to do it in the first place. Between the two of us we had re-designed six Berglund/MCEL web sites previous to these two. We were speeding through these re-designs, perfecting the art of rapid web site deployment – and we were hooked.
Unfortunately we were also in a hurry. Suddenly it became clear I had to push as much work as I could in two weeks as possible because after that it was over. I was out.
So the journals. Unlike a certain someone, I will not release things into the wild – even my own creations – prior to them being officially published. So you will have to wait until the new Interface and JAHC sites go live to view them. However, I would like to spend some time discussing the back-end code I developed.
Those I worked with in the Berglund Center are probably familiar with the template system I designed during the summer. It is a very simple, almost transparent, system that enables a site to pull in two and only two includes files: the header and footer. The magic is that these includes know the specific title for the page, the tabs that should be selected, the heading to place at the top of the page, and even the breadcrumb path. All of this is achieved through one easy to use PHP variable that is defined at the top of each content page. Additionally, a second PHP variable is declared on each content page to tell the system the relative path back to root – so that the entire site can be freely moved anywhere on the server without breaking links. This system worked for our site really well in my opinion and succeeds in completely separating layout from content. All in all, seven web sites on the Berglund servers utilize the exact same core functions.
So the idea was we needed another set of functions to power an online journal. This time instead of separating content from layout, the goal was to reduce redundancy as much as possible while at the same time actually expanding and proliferating the display of content information. What an objective!
At first I considered using a simple, straight forward, no thrills include containing the raw HTML list of articles and reviews in each issue. Such a list could be used on both the issue content page and in the side menu of every page associated with that issue. With CSS it would be easy to re-use HTML content in this manner. But I was more ambitious than this!
No, we needed a database! But, at the same time, we needed something that going to be simple for newbies to maintain. An administrative center would have been required to support a MySQL implementation and I felt this would be too much. Instead I decided upon an XML database. Essentially, instead of the old method of hard coding everywhere (JAHC) or adding entries to various text files pulled by the index pages (Interface) – all the information needed to list articles and reviews was consolidated into a single XML file – one XML file per issue. Essentially the development process is maintained as our developers would still simply copy over the existing folder system to a new issue but instead of updating 2-4 files they just update that one XML file.
Additionally, the information in the XML file can be pulled directly to create an RSS feed on the fly or all XML files in the entire journal can be consolidated into one massive collection to make a journal-wide index page. In fact I considered the index page the greatest bonus of this system because it is a useful feature that has been long-neglected on JAHC and never even existed on Interface.
And also Jeff has assigned me the task of making the book reviews database public and I never got around to it. But now a very similar system will be public. Instead of users getting direct access to the thorough MySQL books review database they can page through the auto-updating book review index pages – the same books, just not as searchable nor exhaustive in publisher information. Small price to pay for something that will literally update itself, I’d say.
Anyway, as long as that description was, this system did not actually take me too long to get running. Only 2 days to build the core code, and then it evolved over the next two weeks as I added new features as I needed them and/or as they were requested.
The truly time consuming part was moving the content from the old design to the new design. At first I was making the conversions with great care, attempting to update the code to my personal standards. I actually got quite far doing this – about three years of issues. However, the end of my employment started to become more ominous and I realize I had to speed things up or risk a newbie finishing off the journal (‘finishing off’ left to the imagination). And so I turned to my old friend the bulk Search and Replace utility. Already, this project seemed to challenge my grasp on regular expressions and I explored more and more advanced techniques to automate the conversion process. But now I simply faced reality and attempted to chew as much content as possible through Search and Replace.
Unfortunately it only sort of worked. The problem is this: The further back in time one travels on JAHC the more articles there were, the longer each article is, and the worse the underlying code becomes. It’s a viscous cycle which depressingly enough meant that my new “speeding through” techniques simply made the older issues take about the same amount of time as the most recent 2007 issues! I think I made it through all but 2 years.
Luckily the Interface was a different issue (ha!) all together. The old interface for Interface (okay I promise to stop) used includes for a similar manner as the redesign. Plus, even more helpful still, the folder layout for this journal was “flat” – meaning all articles existed on the same “level” in the folder system. This gave Search and Replace unparalleled success in automating the content conversion. In face it is my understanding that about 90% of our articles “just worked” in the new template without any intervention at all once the XML files were in place. That’s pretty impressive and I am sure my comrades in the center appreciate the time I was able to spend making the content conversion happen.
I miss my time at the Berglund Center. I really enjoyed being the “expert” on the web site and managing, what ended up being, a fairly considerable team. It was a lot of fun. The cool thing is that many of the people still working there are my friends so if they fail to bug me about my code I will assuredly continue to prod them for updates!
Expect daily updates until I get this place caught up again. I apologize for being absent so long. I was actually working on the journals outside of work as well these past weeks. It certainly was not slavery – I actually took a lot of ownership in the project and had fun trying to make a system that I truly felt would improve the quality of our journals.
Unknown8063 Interest