The Day Job
I'm moving into some new territory at the office. I've started looking up information on AJAX in order to improve a web-based invoice app.
I am currently using a downloaded VB ActiveX DLL to supply the app with rate book information, as it's too much information to download. The DLL provides rates data in XML to the app on demand; the app uses VBScript to load the requested rate book into an XML data island for subsequent client-side processing. The part of the app that edits invoices does all the processing on the client side through the use of XML data islands and VBScript that accesses the DOM. The following picture shows a line item added to an invoice:
Using the DLL to make rates available to the client side made sense when the rates were updated infrequently. We now want to update these rates frequently, and add additional support for updating contract rates on a per-customer basis. IT needs to get out of the receive data-build DLL-publish DLL loop.
Fortunately the current problem helps us solve the original problem that called for a DLL-based solution in the first place. Generic rate books tend to be large collections of data -- everything we might charge to anyone. Add a few of those together, as was necessary from day one, and you could grab a cup of coffee from the break room and be back before the page rendered, especially using dialup. Using smaller, targeted "slates" of contract rates requested on a per-customer basis, we should be able to work within the available bandwidth, while decreasing page render times.
What I want to do now is use XMLHttpRequest to get the desired part of the selected rate book as XML. Once I have this technique down I can use my existing client-side code to parse the XML into the UI. I will then write some tools to allow users in the field to create and update small contract rate books.
We'll see how this goes.
I'm moving into some new territory at the office. I've started looking up information on AJAX in order to improve a web-based invoice app.
I am currently using a downloaded VB ActiveX DLL to supply the app with rate book information, as it's too much information to download. The DLL provides rates data in XML to the app on demand; the app uses VBScript to load the requested rate book into an XML data island for subsequent client-side processing. The part of the app that edits invoices does all the processing on the client side through the use of XML data islands and VBScript that accesses the DOM. The following picture shows a line item added to an invoice:
Using the DLL to make rates available to the client side made sense when the rates were updated infrequently. We now want to update these rates frequently, and add additional support for updating contract rates on a per-customer basis. IT needs to get out of the receive data-build DLL-publish DLL loop.
Fortunately the current problem helps us solve the original problem that called for a DLL-based solution in the first place. Generic rate books tend to be large collections of data -- everything we might charge to anyone. Add a few of those together, as was necessary from day one, and you could grab a cup of coffee from the break room and be back before the page rendered, especially using dialup. Using smaller, targeted "slates" of contract rates requested on a per-customer basis, we should be able to work within the available bandwidth, while decreasing page render times.
What I want to do now is use XMLHttpRequest to get the desired part of the selected rate book as XML. Once I have this technique down I can use my existing client-side code to parse the XML into the UI. I will then write some tools to allow users in the field to create and update small contract rate books.
We'll see how this goes.
0 Comments:
Post a Comment
<< Home