| Strategies for dynamic part management [message #1237077] |
Tue, 28 January 2014 20:08 |
 Joseph Gagnon
Messages: 68
Registered: June 2013 |
Member |
|
|
I am developing an eclipse 4 application that will present a window containing a part stack that may contain two part "types": one for monitoring real-time (pseudo) message traffic, the other allowing the user to view archived messages that have been sent or received at some point in the past. The application will provide a menu allowing the user to select which types of messages to see. For example, the user may choose to monitor incoming message traffic, outgoing traffic, or both incoming and outgoing at the same time.
At any given time, I want only one instance of a given part type to be open. In other words, the user may have both the "monitor" and "view" parts open, but if the user decides to change the "view" part message filtering from, say, inbound to outbound, the currently open "view" part needs to be reset/reconfigured to now display outbound messages - I don't want a second "view" part to be opened. The need for reconfiguration involves re-building the UI for the monitor both incoming/outgoing case, because it will show both views simultaneously, while the other monitor options only need to show one message "pane".
When the application initially starts up I want to automatically open one of the parts with a specific configuration as the "default" (not that it's important, but the "monitor" part set to display both incoming and outgoing message traffic). The user may then choose (by menu) to monitor messages by a different set of criteria (maybe they just want to monitor outgoing); or they may close that part and choose to do something else (maybe open the "view" part to peruse past incoming messages). Either of the part types may be closed at any time and the logic must be able to handle opening the part if it's not open, or reconfiguring the already open part to handle the new mode.
I came up with a way to open a part type and configure it as needed based upon the view/monitor "mode". The logic would look for the part and if found, hide it (which would also cause it to be removed via the EPartService.REMOVE_ON_HIDE_TAG tag) and then recreate it. This has been working, although it seems ridiculous to essentially get rid of a part only to then re-build it with a different configuration and re-add it to the part stack. However, I don't know how to do this in a better way. I would welcome suggestions on a better way to do that too.
Unfortunately, when I tried to add the extra logic to cause the "default" part configuration to automatically open when the application starts up, I ran into various problems that prevent me from accomplishing what I've outlined above.
I would greatly appreciate suggestions on techniques and/or strategies on how to achieve the behavior I've described. My method has worked (until now), but the technique I've used seems hokey and I'm sure there's a better way.
For the curious, the technique I'm currently using has command handlers that will call a "configure" method on a controller class (in "monitor" and "view" flavors), passing the "mode" to configure to. The controller uses the E4 model and part services to get the part stack and configure and add the necessary part to the stack. The part I can't figure out is how to open the "monitor" part in a specific configuration automatically when the app starts up, and still have everything else I've described continue to work.
|
|
|
Powered by
FUDForum. Page generated in 0.02996 seconds
] 
Search
Help
Register
Login
Home
