Community
Participate
Working Groups
The undo, redo, and execute methods supply ui-related info in a parameter that is currently typed as IAdaptable. To avoid introducing more dependencies on the runtime, this should be typed as an Object, similar to the strategy used for IWorkspace>validateEdit. The only flexibility offered by IAdaptable is that we could provide more than one piece of information using that parameter and adapting to multiple types, but the only documented use right now is Shell. The value of having multiple parameters does not seem to be worth introducing this dependency.
See also bug #49497. Will be submitted for I20050315 with the old methods left deprecated.
The new methods have been introduced and old ones deprecated, but this will break clients who do not implement the new methods. Awaiting instructions for the best way to release this code...
Susan, can you please provide a preview for the new methods. As we have discussed somewhen in the past I am using the IAdaptable to tunnel instances of IValidationCheckResultQuery through the operation history (you remember ;-)). I first want to check that I can do this using the new API. In general I am not convienced that we can't use IAdaptable in the interface. When we wrote an article last summer it turned out that you can't use JFace without runtime anyway.
I remember the discussion of IValidationCheckResultQuery and the IOperationApprover but I didn't remember that was how it was being passed. I've just sent some patches and await your reply. As for JFace always needing the runtime...I'm cc'ing Nick because I think he still plans to work on bug #49497 and that there are clients trying to do this.
Yes, I'm still planning on getting to bug 49497 for M6. If necessary, we can include IAdaptable in the utility jar, but I'd prefer not to if it can be avoided. Even if we include that, I would not want to include the adapter manager mechanism.
The adapter manager won't be needed. This parameter is just a "pass through" from the action that invokes the operation history, to the operation that runs, and then back to the specific implementation. The framework itself just hands it along, so it does not matter to me which we do. If it makes a big difference to Dirk, then I think we should keep it, but I'd rather not include it if possible. Dirk - since the action handler is usually invoking the method and providing the adapter, where are you sneaking in the IValidationCheckResultQuery?
I can hack around it if you don't want to include IAdaptable. However, compared to the larger plug-ins JFace, JFace/Text and command plug-in IAdaptable sound like an ignorable class footprint wise. Additionally IAdaptable is a nice way to have extensible API since you can easily add additional arguments without changing signatures. So having it in a "small runtime" is a win as well. Let me know what you decide regarding IAdaptable. As said I can remove the references.
Nick - what do you think? It really makes no difference to me at this point.
Let's leave it as-is for now. I'll consider adding IAdaptable to the utility jar when I get to bug 49497.
Okay - no change for now. Dani - are you ok with this conclusion? I've annotated #49497 to point to this bug so that we are notified if there is some unforeseen reason IAdaptable can't go in the JAR.
Sorry for more confusion here but Kai pointed out that clients might assume that if they have IAdaptable that there is an IAdapterFactory and IAdapterFactory as well. There are references in the documentation to these classes in IAdaptable. So if we move this into the small runtime Jar then we should make a statement that the Jar doesn't contain any adpater factory or manager implementation.
In that case I'd prefer not to include IAdaptable in the utility jar. How bad a hack do you have to do if we don't include it?
Have to add a factory and some additional methods to pass an IValidationCheckResultQuery through the call chain. Currently I am using IAdaptable to pass the object.
I'm including IAdaptable in the utility jar anyway. It's small and powerful.
Closing this bug. IAdaptable will remain in the interface as it is now in the utility jar and "on the list" of acceptable classes, and it helps the refactoring integration. Dani has documented its use as permissible in the DefaultUndoManager.
