Posted by Allen on May 31st, 2005
It’’s a reality that all current Polymer development is happening alongside the development of my primary Polymer application, which for now we”ll call Data Center. (It’’s a proprietary app for data management at my company, so the details of it have to be pretty unimportant in this discussion). This app is actually the evolutionary ancestor of Polymer, though it’’s developing into a Polymer instance itself.
The latest push in project development is in-house live production, which basically means fine-tuning Data Center to operate as an application of the default Polymer installation, rather than just a modified hack of Polymer. A side-effect of this push is that I can”t really do much other development on Data Center until this conversion is complete, because I”m making a boatload of changes to the underlying code which will simply break Data Center in a slew of unpredictable ways if I do it piecemeal. Combine that with a workload that’’s had me out of the office on special projects for half of the last couple of months, and you get a production schedule that pretty much crawls, if anything. But the newest mandate at work is to set up — in the next two weeks — a section in Data Center that will require not only stabilization of the Polymer app, but the addition of two new features: targets and interfaces.
Targets are actions that can be targetted directly from external links — you can link directly to a specific app action, and Polymer will make sure you log in, then send you through the action (unlike the present method whereby you can only link to the app and have Polymer present you with a login screen and then display the app’’s “Welcome” or default template.) This is the same as you expect to see on Sourceforge or most any other secured site: if you”re uncredentialled, the app asks for your credentials and then sends you on your credentialled way; but up to now, Polymer hasn”t been set up for that.
We”re also going to have to implement support for multiple interfaces, so that a single application can have two or more totally different looks and feature sets, depending on the interface being used. Think of it as separate entrances to the same application. As an example, in many businesses, you need a staff entrance that’’s completely separate — looks and functions differently — from the customer entrance; some restaurants have separate entrances for different kinds of customers: drive-through, walk-up, and sit-down customers all need a different set of protocols to meet their requirements. Multiple interface support will allow Polymer to present any number of different feature sets to the user in a similar way.
With a two-week deadline I am pretty excited. It means my job is pushing me to get these features implemented and fully stabilized. With this I am suspending some of the more aesthetic elements of our first release; basically I need to get this tool working for my employer, and after that focus on releasing code. But it gives me a clear goal, and once it’’s done I should have a solid (if poorly written and buggy) code base to share.
News | No Comments »
