Community
Participate
Working Groups
This will require a ScopedPreferenceStore with "session" scope, as well as a mechanism for persisting session specific key-value pairs through RWT. (More details will be possibly added once I start working on this...)
Created attachment 92115 [details] Session Scope Preferences v1 This patch adds support for AbstractUIPlugin.getPreferenceStore(). A few things to discuss: 1. I use an internal class from org.eclipse.core for Base64 decoding / encoding. This is needed by the spec. Is it ok to have this reference? The alternative is copying the class from org.eclipse.core. 2. Currently there is no notification to preference listeners when one does a SettingStore.loadById() in RWT. Should we change that? I've investigated the possibilities and I'm not sure if this is worth the complexity. 3. Currently only the preference values are per session. The node structure is global. I was not aware of this until today :-o. For "normal" use via getPreferenceStore this is not a problem. However for more advanced use, for example via SessionScope.node( "..." ).remove() this could have unintended consequences. Let's discuss 2 and 3 in the next sync up call. Elias.
Created attachment 92124 [details] Test Project This project contains tests for the session scoped preferences. To run launch the enclosed RAP Application.
Created attachment 92250 [details] Session Scope Preferences v2 This patch addresses the concerns from comment #1 with regard to point 2. A SessionPreferenceNodeCore servers as the glue between RWT and the session preference node. It will forward change events to the preference change listeners, once loadById(...) is called in RWT. As discussed points 1 + 3 are ok.
Created attachment 92251 [details] Test Project v2
Created attachment 92252 [details] Sample Project v2 This project is a joint example for RWT Setting Stores (Bug #220476) and this bug.
The implementation is now available in CVS-HEAD. There was still a problem with sessions and the global usage of ScopedPreferenceStore. I've changed the ScopedePreferenceStore implementation to work properly using SessionScope and non SessionScope contexts. Elias could you please verify that this doesn't conflict with any other use cases. I also refactored some package names due to the rule that RAP provides a subset of RCP.
Adjusted target milestone.
Frank, 1. I looked at your changes. We now have a unique node hierarchy "per session", meaning that all nodes starting from "/session" will be session specific. This is ok from my POV, as it makes the whole mechanism easier to explain: not only the attribute values are session specific but the nodes too. I currently do not see any conflicting use cases. 2. I noticed you copied Base64 from org.eclipse.ui.core.internal.preferences. I thought we wanted to avoid this (?). Elias.
in reply to comment #8, 2: I copied Base64 from the original workbench plug-in codebase. Personally I would have prefered to use the internal reference to avoid the code duplication as agreed on, but as I detected that the RCP workbench plug-in also has its own version I copied this just to have the reference in place for import statements in case we adapt the rest of the package and to keep as much as possible in sync with the original workbench stuff. Still I'm not convinced that using the copy and paste approach is better than the usage of the internal version, since now at least 3 copies of the Base64 class exist.
As the implementation is available in CVS-Head and as it seems to work reasonable a change the resolve-state to fixed.
