I've been working on a system for a law firm that allows them to quickly generate legal documents. Users complete a Q&A process and a PDF pops out at the end. The logic is more sophisticated than it sounds though. It's now evolved into a records management system and document management system as once generated as document have a particular life-cycle or legal purpose. The system plugs into the Alfresco ECMS which is an impressive little open source project.
We originally started with Struts 2.0.1. Some of the challenges have been managing the massive increase in scope and the view and workflow tailoring requested by every new corporate client. At my last count this application had over 100 actions in struts.xml. Lessons learned: I've been scared-for-life and won't ever use FOP again (http://xmlgraphics.apache.org/fop/).
My pet project involves data mining and analysis. I've been using Struts2.1 as a SOA framework where the actions output a response as json, xml, an html fragment or html page depending on how it was requested. Struts does an excellent job at that. The RIA is build upon YUI. The biggest challenge with this project is dealing with large datasets. Every operation hits a bottleneck, from javascript being too slow to the servers having insufficient [insert any resource]. It's a constant juggle between optimzing algorithms and reoganizing resources.
I have new appreciation for what Sergey Brin & Larry Page achieved in the years before they had money or resources.
Lessons learned: Don't bite off more than you can chew Ted Husted wrote:
While outward facing web application get the most publicity, I know that most of us are heads-down on internally-facing applications designed for fellow employees to use over the corporate intranet. I'm trying to put together a list of the typical types of applications that enterprise developer write in real life. For example, my last project involved a system to track drafting, granting, monitoring, and enforcing water permits administered by a government agency. We would create an initial record for a permit, and then add child records to track progress through the workflow, and also update the master record along the way. For management, a key item here is a tracking report, which we exported to Word (using a third-party tool) for better formatting. For engineers, a key item was a flexible search system to quickly find a master or child record. Other interesting features are workflows where one task leads to another. When we completed one task (child record), the next is often implied, and so we had a workflow that would default the next task to work on when a current task was closed. Another interesting requirement was that sometimes master items were merged under another uber-master-item, becoming, in effect, child items themselves. In most cases, the application simply exposed business models that we designed into the database, so the application has little business logic of its own. Most of the workflows were designed to find, list, edit, or view one database entity or the other. So, if anyone else is up for sharing, I'd be interested in hearing what sort of things other people are doing these days. (If your not comfortable posting the list, feel free to mail me direct.) -Ted. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
