And here’s what their current “Reports” module looks like in their old site.
Here’s what the old Reports.asp page might look like:
<h1>Reports</h1>
<form id="frmReports" action="reports.asp">
<label>Report Type</label>
<select id="report_type">
<option value="1">Tithing</option>
<option value="2">Member List</option>
<option value="3">Attendance by Campus</option>
</select>
<br />
<label>From Date</label>
<input type="text" id="frmDate" />
<br />
<label>To Date</label>
<input type="text" id="toDate" />
<br />
<input type="submit" value="Run Report" />
</form>
<div id="rptResults"></div>
<%
'A bunch of complicated code to handle the form post and manipulate the html in the "results" div based on the report type would pollute this page.
%>
Note here that I’ve added our new report type, “Attendance by Campus” onto the old report type options. Obviously we don’t want to add to what is likely already a complex page. We want to do this in our new web app! The problem, though, brings up the first proposition in our pattern: 1. Complex server form posts can be hijacked with Javascript. We’ll handle this in the page’s javascript. What we want is to NOT post to the old ASP server page, but to reroute the page to the new web server:
$(document).ready(function() {
$("#frmReports").submit(function(e) {
var reportType = $("#selRptType").val();
if (reportType === "3") {
$.get('http://localhost:3000', function(response) {
//do something here
});
return false;
}
return true;
});
});
I’m not going to go into the details of the logic behind the new web server since we can just assume it performs some business logic on the database and renders the appropriate chart. I’m also not going to handle how authentication should work to allow the legacy app to ensure it has access to the new one. You can handle all that with a wide variety of solutions outside the scope of this article. As you can see in the code above, we’ve hijacked the form, checked to see if the new report chosen needs to go through the new server or the old server. If it needs to hit the new server, we just make a simple web request and get back the response. Now what do we do with it? This brings us to our second proposition: 2. New server technologies can be hybridized into the DOM of the old server. How do we do this? In our case, we could do something like this:
$("#results").html(response); We essentially bypass all that old server logic that’s manipulating the “results” div and just dump it into the DOM. The beauty of this approach is that if there’s additional behavior on the old web UI that needs to happen, we can manipulate anything we want in the old page’s Javascript because the new page logic is every bit as much of the DOM as the old one. Just keep in mind here that any extra scripts you load from the new page are going to be loaded asynchronously. There are some solutions to this described [here]. This obviously isn’t a silver bullet, and there are some considerations you need to think through before doing this. Do you *really* want to create a deep UI dependency between the two server’s pages via Javascript? But for small features like this, it works great. I was able to use this approach for what I was doing and be pretty content with it. It’s a great way to bypass the pain points of old server technologies and redirect you from the 1990’s to the 2010’s.
