This is a discussion on Command pattern variation? within the Software Patterns forums, part of the Testing category; Hello, I'm designing a UI framework to use in our client applications. The goal is to allow for the ...
|
|||||||
| Register | FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
|
|||
|
Command pattern variation?
Hello,
I'm designing a UI framework to use in our client applications. The goal is to allow for the applications to use a multi-document model, where multiple documents showing information about different domain entities at the same time (eg. a document showing information about a Customer, some other document showing information about an Order, some other document showing a report about Sales, etc.). These documents are 'active' documents, in the sense that they allow modification of the data they are showing, and also several other commands related to the entity they are displaying (eg. 'Send an email to this customer', or 'Cancel this order'). Following the Command pattern, I've developed a framework that swits the needs for encapsulation of the commands logic. However, I'm having trouble with finding a nice solution for the multi-document side of it. What we need is a way for each document (implemented as a component that can be hosted inside the main application along with others) to display its own controls on the main interface (window). There are two forms of "UI merging" between the hosted documents and the main window: a) Allow for the hosted document to ADD controls to the main window: e.g. add a toolbar or a sub-menu to the main menu. b) Allow for the hosted document to ATTACH commands to the main window controls: e.g. redefine what commands are attached to the Open, Save and Save As menu items. The controls the documents will need to attach to are not fixed: some documents will want the Open, Save and Save As controls, some others will want to attach to any other controls. What I have so far is the following model: the relationship between the main application and the sub-documents will follow the Plugin pattern, so we can easily add new document types. Document components will be required to implement an interface (e.g. IMergeable) that will export a objects "CommandMerger", which in turn will have two collections, containing a) controls to add to the main interface and b) pairs of text ids and commands, each id specifying a main window control to attach the command to. Then, the main window will be able to do the interface merging each time the sub window for each document becomes active (we plan to use a tabbed interface) and deattach the commands and hide the added controls when it becomes inactive. This approach has several differences with the 'standard' Command pattern, I think these two are the main ones: * while the Command pattern acknowledges the possibility of multiple documents (multiple receivers), it doesn't account for documents *providing* new commands and controls to the Client (the application). * as a consequence of this design, some commands (and controls) are created by the documents and provided to the main application, and some commands (and controls) are created by the main application. The main application needs to manage these commands while the document is active, but the lifecycle of these commands and controls provided by the document is determined by the document's lifespan. My main problem with this design is mainly about the application/documents interaction: document components need to know before-hand the main application control ids to attach to, and they need to create controls by their own to pass to the main application, which can be complicated or even impossible in some platforms. Any suggestions, or pointers to alternative designs/models/frameworks? Regards, Juan Ignacio Gelos Evolutio Software |
![]() |
| Thread Tools | |
|
|