Developing a Composite Application from scratch (2)
Karsten Lehmann 31 May 2009 15:19:25
Welcome to part 2 of our blog series about the development of the "Mindoo CA Document Management System", a DMS based on Composite Application technology.Today, I would like to tell you something about the general idea for the system.
Here is a draft of the user interface I have in mind:
That looks pretty simple. The UI consists of three main area:
The user selects a filing element in the filing tree component in the upper left. Depending on the selection, the upper right component displays a list of all the documents that are stored in the system for that filing.
The component at the bottom contains a preview of documents selected in the document list.
Instead of that preview, the document can also be opened in edit mode in a new Composite Application page:
The page contains a component in the middle with the document in edit mode. Another component is used to display and change the document's filing. Depending on the type of the document, there may be other useful helper components in the layout. We will define such a page layout for every content type to offer an individual component setup.
Some other thoughts for the system:
Filing tree
The available element types and structure constraints of the tree depend on the individual use case of the user. For some users, it may be sufficient to have something like a "folder" node that can be nested in an unlimited depth. That would make the system act like a kind of Windows Explorer. Others need address management elements like a "company", "department" or "person" to e.g. store mail conversation with their customers.
That's why we need to find a quite generic approach for the filing. Our default filing component should contain a preset of useful elements. But it should also be possible to completely replace the filing component without the need to change the rest of the system.
Document's filing
As mentioned in the first posting of this series, we should avoid storing too much information in the documents. That why I prefer to only store an internal ID for the actual filing element in the content documents, not the whole filing structure (up to the top filing element). That reduces the need to update many documents when somebody moves filing tree elements, but we will have to think about a proper presentation of the data. A classic Notes view that is categorized by the filing tree nodes won't help us a lot.
So far for part 2 of the series. Time to start coding.
- Comments [5]