Document Imaging Mogul

Lately at work I’ve been working on an aspect of our program for storing images and drawings and relating them to a sales order line.  I was charged with making the ground level of it as generic as possible, so we could use it within our ERP app and for any other app that may need it, which we just happen to have.  Each individual instance that needed such storage could write an upper level to make use of the generic storage layer.

It was a nice break and gave me a little creative license to come up with something.  It was also nice to make something that didn’t depend on all the previous framework code and get to tinker with the basic building blocks of Spring and Hibernate.  That’s one thing that has always bugged me with big built up frameworks.  When you want to just take a small portion of something and start building something completely different, you end up wasting a lot of time just trying to untangle it from what it was attached to before.  Wasn’t that what dependency injection was supposed to free us from?  Maybe if it’s done right.  🙂

Anyway, it’s been an enjoyable experience and after pretty much completing the base generic layer, I moved on today to use it in the ERP system for our images and drawings.  I also moved it into a separate codebase for our other application that needs it and will help integrate it there when the current developer is ready.

I basically made it to store any type of file as an attachment.  What I came to realize is that I had probably created a very simplistic document management system.  The base system is only concerned with storing, retrieving, and deleting the attachment and giving an id via a simple database table that tracks to the storage location scheme (which is Spring injectable).  Each instance that has a need for such storage can layer on it’s own specific search or naming needs.  For instance, the ERP part that I’m concerned with right now only needs to map order lines to the attachments, keeping it’s user file name so the user can relate to it.  The other current app, layers a virtual directory system on top of the attachment storage to make it stay consistent with what the end user is used to.

All in all it’s pretty neat.  Not rocket science mind you.  It’s not that much code.  The time was taken thinking about what I wanted and how it would be used and refactoring it to how I wanted it to be.  It’s been “existing framework neutered” so hopefully the core development team won’t complain to much, but it makes it easier for our development team’s other applications.  Programming religious wars are always an annoying thing.


Tags: ,

%d bloggers like this: