The new era has begun…

Today I hacked our legacy myUMBC portal code to generate XML output
for the registration eligibility function. The goal is to eventually
get away from the big, monolithic app and separate the business logic
from the presentation. Registration eligibility was a good place to
start, because (1) it’s a simple function with simple output; (2)
we’ve gotten a request to display registration eligibility within MAP,
so we needed to figure out a way to share the code; and (3)
registration eligibility still talks directly to the HP3000 mainframe,
which makes it impractical to do code sharing via Perl modules,
libraries, etc. So, this is what we came up with. It’s the first
step in coming up with a web-services type API for our back-end SIS
business logic.

The first thing I needed to deal with was the Perl code itself. The
legacy myUMBC code, while nice and modular, is very HTML-centric.
The business logic stuff is all mixed up with the code for HTML
generation. The code works by building data structures to represent
HTML objects, and the business logic bits are all built into those
data structures. Separating this stuff out is not really major
surgery, but it does require some work. I’ve managed to do this for
the registration eligibility code, but I still need to put a run-time
flag into the code to toggle XML vs. HTML output. Also, there will be
the ongoing challenge of dealing with error conditions and generating
valid XML in these cases, but we’re getting there.

On the actual XML front, the main challenge is defining what exactly
you want to output, coming up with a spec (DTD), and sticking to it.
This can require quite a bit of thought, and needs to be done before
any actual code is written. For registration eligibility, the DTD I
came up with is pretty simple:


<?xml version="1.0"?>
<!ELEMENT registration (eligibility)>
<!ELEMENT eligibility (status*)>
<!ATTLIST eligibility status (eligible|ineligible|registered|error) #REQUIRED>
<!ELEMENT status (description,extra?>
<!ELEMENT description (#CDATA)>
<!ELEMENT extra (#CDATA)>

And some sample XML…

<registration>
 <eligibility status="ineligible">
  <status type="academic">
   You are academically ineligible to register.
  </status>
  <extra>
   Your GPA is too sucky for you to continue
   attending the university.
   Please go away.
  </extra>
  <status type="financial">
   You are financially ineligibile to register.
  </status>
  <extra>
   Your parents didn't send us any money this
   semester. Please go away.
  </extra>
 </eligibility>
</registration>


Coupla notes here.. I used the generic tag name “registration” with
the idea that down the road, the object will contain other
registration related stuff besides eligibility. We’ll see if that
actually happens. And, although I do include text-based descriptions
of eligibility status, these are only intended to be guidelines.
Applications can use the descriptions as-is, or key off the “type”
attribute in the “status” tag, and display their own messages.

The code generates this XML using the same Perl objects I wrote to
construct HTML. It seems to work OK for generalized markup, and
guarantees that the output will be “clean”.

Next up is to see how this works when we pull it in as a uPortal
channel. To do this, we’ll need an XSLT stylesheet and we’ll need to
set up a “Generic XML/XSLT Transformation” type channel (rather than a
web proxy). We’ll need to use our custom local connection context
code to connect, and it remains to see how that will work with a
non-web proxy channel. Should be fun..

Well, I learned something new about IE today. If you use an empty-element tag in a <script> declaration, for example:

<script language="javascript" src="/foo/bar.js"/>

It breaks IE. Apparently, IE doesn’t treat the trailing slash as a close tag, and treats the rest of the page as an inline script. Firefox, as expected, has no problems with this. The workaround for IE is:

<script language="javascript" src="/foo/bar.js">
</script>

This affects IE 6; don’t know about other versions.

Like everything else around here, we learned this the hard way, after I made some mods to the Student Parking Registration app and it broke for IE users. Fun fun..

On another front.. we’ve got something new coming down the pike. If I can ever get away from all my various menial maintenance chores (FAR, Parking, PlacePro, etc. etc. etc.) we’re going to attempt to do a pseudo-quasi-web services app. It’s not “real” web services, but I’m going to mangle the legacy myUMBC portal code so that various functions can return XML for consumption by other apps. Background: We’ve been asked to display registration eligibility status inside MAP (UMBC’s homegrown kitchen-sink retention-aid-transcript-displaying-advising-scheduling-coffee-making web app). Now, the hitch here is that we currently pull eligibility info directly from the HP3000. It’s all there in the Oracle SIS, but no one has coded up the SQL to fetch it, and our development resources are spread too thin (doing crap like FAR, PlacePro, etc.) to do it right now. And even if we did it, the code would have to be duplicated between myUMBC and MAP, which is just a bad idea anyhow. So, I’m going to hack myUMBC so that MAP can call it, pass some magic params, and read back an XML stream of registration eligibility info (which can be parsed, transformed, etc. as desired). To make this happen, we need to do a few things..

1. Move MAP off its current SGI hardware and onto a more modern platform, where we have the LWP::UserAgent and Crypt::SSLeay Perl modules installed
2. Figure out a workable DTD for the XML data, and stick to it
3. Modify the legacy myUMBC code so it can output XML (via a custom URL, custom CGI parameter, etc.
4. Modify MAP to call this routine using LWP::UserAgent, parse the results, and display them

Like I said, not really “web services” in the official sense, but the same kinda thing. This seems like an easier, and possibly better, way to do code sharing without having to do major surgery on the legacy code. As with everything else, we’ll see how it works in practice.