Commands

[jwray]

Magnus,

glad to hear you got it working but I have a question. Where, and why, do you have to fire a focus changed to get this to work with the JIDE integration? I don't have to fire any focus events to get the executor stuff to work fine.

Another point. Did you download the new JIDE integration code I committed last week (see http://forum.springframework.org/showthread.php?t=32115) as it contains some bug fixes specifically related to focus events. The executors are effected by these changes.

I've never uses the security integration with shared commands, but I guess I'd start with having an entry in the securityControllerMap of the securityControllerManager with the key being the shared command ID.

As for the getting the source, I usually connect to subversion directly and download from there.

Jonny

[magpor]

Jonny

I'll check out your changes but since I altered your integration alot, I dont have the editors at all only a workspace that is permanent, I don't know if it gives me to much.

The change I made is not really a change it was more a mistake from me where I had commented out some code I needed. It was in the ApplicationPage in the createDockableFrame method where you fire focus lost/gained when you docking frame receives the event. One thing though, I was expecting the view method registerLocalCommandExecutors(); to be enough to get the functionality I wanted where the commands are changed when the view looses/gains the focus. But it does not seem to work. Instead I have to register and unregister them in the focus lost/gained methods in each view. I remember a note about this before where the exact same behavior was wanted so i also did it that way. Thats also the reason the application page must fire focus lost/gained.


Yes I also get the source from subversion but i would like to include the source in my intellij roject so I can step into the code. So if there was a mvn src:src task it would be great.

About the security I thought that it would work the same for all commands since they implements the Security interfaces. I've noticed that the ObjectConfigurer is acctually using he security id to authorize the command but it does not work proper anyway. As I said I'l get there eventually I'll tell you when.

Magnus

[jwray]

Magnus,

Overriding the registerLocalCommandExecutors in your views should be enough, it's all I do. I certainly don't register and unregister the executors in the focus method and they work fine. This was tricky to get to work with the JIDE docking though, so maybe your modifications have effected that?

By the way, I'm curious, what functionality did you need that made you change the integration?

See what you mean about Maven and src:src. I'm not an Maven expert so can't really help you there.

Jonny

[magpor]

Jonny

I dont want editors at all I just want a workspace that is permanent. Offcause I could keep the editors and let all my selection end up in the same editor but the customer just wants a simple layout without the editors.

Ok maybe I managed to destroy the expected functionality when I changed your integration. In the ApllicationPage I haven't really changed anything when it comes to fireing focus hanged events. I expected the registerLocalCommandExecutors to work in such a way that when a view get the focus the framework will shift the local commands to the active view. Is there anything else you have done to get this to work that I have missed then?

Yeeah the mvn src:src would be helpfull but I haven't seen it working. We are working hard on getting the project structure in perfect condition so we can let the customers developers into it. As it is now it's impossible since spring rcp is changing alot and I need to keep up with the changes since so much new cool and usefull stuff keeps coming all the time. I just hope that spring rcp want die out because that would hurt us alot. I'm tinking about puttig some of so4it's (my company) people on it to get a higher understanding. We have seen that rich clients with Java Web start is a revlution for the customers and we are aiming at becoming the best suppliers on the technology in Stockholm/Sweden

Cheers
Magnus

[jwray]

Magnus,

I guess I still don't see why you need a workspace at all in this situation. Couldn't you turn off the workspace and use a normal view in it's place?

Your expectation with regards to registerLocalCommandExecutors and focus changing is correct, and that is what happens in my application, and the demo application.

It's hard to know where to look since I'm not sure what changes you made. As I mentioned, this took some effort to get working initially, but that was quite a while ago. The changes I submitted last week did change things as JIDE changes their focus event model a little. Also, I'm running against the release version (0.2.1) and not the 0.3 snapshot, I don't know if that makes a difference?

I'll dig into the code a little to refresh my memory and let you know what's needed to get this to work.

Jonny

[jwray]

Magnus,

I went back to my code and ran some tests. The important part with respect to enabling the executors to follow view selection is the dockableFrame.addDockableFrameListener call in the createDockableFrame method of JideApplicationPage.

The specific dockable frame listener that I add basically converts the Jide dockable frame events into Spring RCP page components events.

There's also a couple of other listeners that are required to cover specific cases with the workspace/editor implementation. One (addDocumentComponentListener call in the addDocumentComponent of workspace view) deals with the case when all editors are closed, and the workspace becomes empty. The other is the registration of a specific FocusOwnerChangeListener in the constructor of JideApplicationPage. This deals with the case of an editor being selected after a view. This is not dealt with by the usual Jide event mechanism.

hope this helps.

Jonny

[magpor]

Hi Jonny

Ok I'va been digging through this. You have in your code something like this

dockableFrame.addDockableFrameListener(new DockableFrameAdapter() {

public void dockableFrameActivated(DockableFrameEvent e) {
fireFocusGained(pageComponent);
}

public void dockableFrameDeactivated(DockableFrameEvent e) {
//Must not fire focus lost since non view component may
fireFocusLost(pageComponent);
if (e.getOppositeDockableFrame() == null) {
fireFocusGained(workspaceComponent);
}
}
});

This is ok when you are shifting focus between view's only. BUT since other components may take the focus it means that when selecting a menu, which can also be tied to the global commands, a focus lost event occurs and the view looses its focus. Since the opposite fram is null, remember its a menu selection, the workspace will get the focus and the global commands will be set by the workspace instead.

This is a BIG problem for me so what can I do?

If each view ALWAYS must define a command executor for all global commands we could remove the fireFocusLost(pageComponent); in the dockableFrameDeactivated method. This would make the problem with the menu selection disappear since only when view are selected would the commands be set. The problem still exists with the workspace though. (Remember I have a workspace that does not use the editors so maybe I should redo this and have it as a normal view, which is not closeable etc). I need to listen for focus gained on the workspace view so I can fireFocusGained on it.

I will continue investigating this and let you now what I've done. Please feel free to give a comment if you think I should skip the workspace or anything else

Cheers
Magnus

[jwray]

Magnus,

Dealing with the workspace has always been the biggest problem with respect to the global executors and focus. The e.getOppositeDockableFrame() == null was always a bit of a hack to get this to work. Since you don't use editors maybe using a non-closeable view would be a simpler solution.

Also, look at the most recent codebase, especially JideApplicationPage and WorkspaceView. I checked some changes in maybe 3 weeks ago that dealt with these events and one change was to get rid of the e.getOppositeDockableFrame() == null check. Following some advice of the Jide guys I now use a FocusOwnerChangeListener that checks to see if the focus has changed to the workspace view and fires a focus gained method on that. The problem you mentioned, with menus etc., was brought up as a reason not to use the getOppositeDockableFrame hack.

Please let me know what you find.

Jonny

[magpor]

Hi Jonny

Well good I found it again then :-) Sorry for not looking at allready existing code but it's kind of fun to find out for yourself and to feel special :-), atleast until you put me straight...


I think I'll go with the non closable view, maybe I'll go for the workspace later if I feel there is a need for editors, which there might be.

I want to thank you for your help, it is really nice to have someone to bounce ideas with. I'll get back with more info when Im done with this part.

Cheers
Magnus

[jwray]

Magnus,

hope this solves your problems. If it doesn't, or other problems are found in this regard, please let me know. I'd like to be certain that this piece of the integration code is robust.

And, yes, from what you've said a noncloseable view would suit your purposes better than the workspace view, which is only really needed for editors.

Jonny