?

Log in

No account? Create an account

t3knomanser's Fustian Deposits

End of the Week

How Random Babbling Becomes Corporate Policy

run the fuck away

Mad science gone horribly, horribly wrong(or right).

End of the Week

Previous Entry Share Next Entry
Tom Baker
I keep some balls for juggling in my cube. Since the weather's been fairly nice (too hot today), I've been going outside and juggling on my lunch break. Some fresh air, sunlight, a little exercise. Basically, things that are anathema to programmers.

Anyway, as it turns out, over in Market Square, I stumbled across another group of jugglers. We swapped some info, and hopefully will meet up again soon. They have much more by way of juggling supplies- I was just starting to get used to juggling rings (still have a mental block about clubs for whatever reason). Apparently, those guys have been running around getting kicked out of public places for juggling in them.

Speaking of juggling, I've been doing work too. So please, let me explain how


Caveat: The application discussed here has only a handful of users. It is not a heavily loaded application and it runs on its own hardware. This means that it actually performs “acceptably” in most situations. But seriously, folks- there’s a lot of issues with this design.

Someone requests an ASP on your server. The ASP is loaded by the ASP runtime. Based on the data it wants to display, it populates a multi-dimensional array. Each “column” in the array represents a separate query that you want to run against the database. Each “column” has six “rows” (an Nx6 array, where N is the number of queries to be run). Each row has a specific meaning, including the name of the query to run (all SQL is stored in the database, you see), extra options on the query, like sorting overrides, etc.

The ASP then calls a method on a class, passing this array in as the parameter. Based on the input parameters, the class retrieves data from the database. The first query retrieves some basic metadata about the screen to be displayed. The second query retrieves the individual elements to be displayed on that screen. Then, for each column in the array, a query is run to retrieve the ACTUAL query we want to run. Except the SQL code isn’t stored in the database. Data ABOUT a SQL statement is stored in the database, and the class retrieves that data and mashes it into a SQL statement, which is then run against the database. This whole shebang is then mashed into a row-oriented XML file (as opposed to a hierarchical XML file- y’know, the kind of data XML is MEANT to display).

The ASP receives that XML file from the class. Now the ASP passes that file off to a different class. That other class wraps a set of methods around the XML so that the ASP can request specific data in order to display it. Sometimes the data is just plain unmarked strings, but usually it’s HTML.

Sometimes, like when outputting a list, the HTML won’t operate properly without client-side javascript. Even though the javascript is the same on every page, there’s no method to retrieve that javascript from the UI class. You have to hard code it in.
Hey, at least it automatically pages large recordsets for you. That’s something, right? Well, it is, except for the fact that it doesn’t cache any of this data. Which means that when you click a paging link this ENTIRE PROCESS IS REPEATED.

Lo, this is how it shall be, forever and ever, the methods of the TPM Screens. And there was much rejoicing.


All bitching aside, I'm starting to get a feel for how the app works, and I'll be ready to really dive into things next week.
  • And there was much rejoicing cowering, twitching, and all-around head asploding

    FTFY

    I still can't believe nothing's cached! Is there even a way to track one user's full interaction with the site, like a servlet-style session?
    • Oh, it's got Sessions. But all of the data coming back from the DB has to be gotten EVERY TIME there's a request.
      • But I thought you could use sessions to track that sort of thing! ={ I recommend another snarky quote on your whiteboard: "I'm going to instantly forget anything you tell me, and will ask you to repeat it again every time I see you. TPM doesn't cache, so why should I?"

        (Okay, not really)
  • Wow. So...

    Step 1: ASP receives request.
    Step 2: ASP calls a data access class.
    a.Data Access class returns Query Table, which looks like:
    Q1, Q2, ...QN
    Query Name, Query Name, ...Query Name
    Option1, Option1, ...Option1
    Option2, Option2, ...Option2
    Option3, Option3, ...Option3
    Option4, Option4, ...Option4
    Step 3: ASP calls data generator.
    a. Get screen metadata.
    b. Get elements.
    c. Iterate through query table.
    1. Use column to get query data.
    2. Run actual query.
    3. Get back recordset with real data and package into an XML table.
    Step 4: ASP uses XML data wrapper functions to return just the records the user asked for.

    It sure does have that "Gee wiz. Look what I can do!" feel to it. Maybe a layer or two of abstraction could be cut out? How about the web designers. Can they even make a web template without programmer assistance? (sigh) You'll have to let me know if they have a good reason(tm) for doing this. That was just painful to read.
    • (sigh) I should have expected the whitespace stripping.
    • That's the long and short of it. As someone I work with put it, "Basically, this application was developed by two extremely smart people that hated each other and were trying to out 'genius' the other." Everyone else just calls it "overengineered".

      Long story short- no, there's no reason that it all needs to be there. It won't be removed, mind you, because they can't spend too many IT resources on those sorts of improvements (unless we can wedge them in as part of other projects).

      For this app, there are no web designers. This is basically a mainframe-style application implemented using web technology. Heck, developers need to go through every month and scrub some data afterwards because customers can't get their data in on time (and aren't allowed to enter it after the deadline, but devs can). We can spend time doing that, because it's billable.

      Basically, the assorted cruft and bureaucracy of a large corporation.
Powered by LiveJournal.com