CM02 customer document management is complete and ready for UAT.
The biggest problems faced during development of this requirements were management of sessions & the lazy loading of customer documents in the Client POJO.
Uploading on the flex side is developed from the file upload & php article from coding cowboys:
http://weblog.cahlan.com/2006/09/uploading-files-with-flex-and-php.html
I then got the apache commons file upload libraries to lend a hand on the backend.
The actionscript from the above link handles the getting of the file from the file system and posts it off to our usual service, tagged with add document.
The request is then parsed using the apache commons library into a FileItem where we can extract the content & file name etc.
The request comes with the client key, we fetch the appropriate client and its file set adding the new document and saving the client.
One of the biggest problems we had with this as i mentioned earlier was a session problem. When logged in there is a session id associated with the authenticated user. However, the file upload implementation in flex begins a new session. There are numerous links and posts about these flex session id tomcat problems on the web. Our solution was to setup another request handler which can pass back the valid jsession id to flex itself. We then append this session id to the upload url which ensures the upload request is authenticated. The same issue occurs for file download.
The other issue i noted earlier was lazy loading and while my post on the hibernate forum was a start it wasn’t the sliver bullet to all my problems.
In the end I wrote a session interceptor in Spring which i mentioned as on wish list in a previous post – this however became essential to make the document lazy loading work.
I also had to the spilt the file POJO into two separate POJOs one for the file details and one for the file content itself. This is because as per the hibernate post all hibernate properties default to eager fetching and changing this through writing an ant task to change the byte code is not a very “done” thing. So as per the hibernate post i have setup an @lazyToOne relation between the File & FileContent POJOs. This now means when we do a fetch on a customer for populating the various customer tabs we are not fetching there documents as well, just a proxy list containing their file details. Before this was implemented even with small files there was a visible drop in performance of fetching customer details. This has now thankfully been resolved.
Also becuase of the spilt the adding of a file is a transaction and as such has been wrapped by a spring transaction interceptor (see my previous post on transactions for details).
Further I have implemenated a many to many relationship on the data model side to open the scope for one document to be linked to more than one customer. This however, will be beyond scope for this project iteration.
Now my task is to go back over all of the developed CMS components and do some ironing and polishing.
David is already writing JUnits for some of his code so I had better not let the side down. For GUI testing we are going to rely on manual use cases and checks as opposed to some of the automated GUI testing software out there – due simply to the ever tightening time constraints placed on the project.
