This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Use case: I wish to toggle back and forth between Design and Source views. I wish to navigate in either view and when I toggle to its peer view the current position will be synchronized. Whatever is current postion in Diagram will be current in source and vice versa. For example: I am looking at Design view. I have selected a Recieve activity. I wish to see its source code. I switch to the source . This takes me to the proper postion in the source view. I stay in source view for a while. I page down to some other part of the file. In source view I have now selected a Reply activity farther down in the process. I switch back to Design view. The Design view shows the Reply as selected. Today in 5.5 EP, I cannot do that use case. I can invoke the "Go To Source" to take me from the Design element to its corresponding source. But if I navigate in source and return to Design view, it has remained where I left it. If we implement constant source/design current position sync, we may not need the Go To Source action at all. It would be redundant. Questions and concerns: - Are there any use cases where the positional sync would be undesirable? - Are there any situations where the attempt to maintain positional sync will be problematic and risky - i.e. as user edits source file, it may be temporarily malformed. We need to make sure the positional sync implementation is defensive enough that it does not blow up becuase of transient activity in source editor.
I strongly disagree with this idea. The sync is undesirable because the user specifically wants to control his view and have them be the same as where he left them. Any time the tool begins controlling the views, especially when they change without his consent just because of a side effect in another view, he will get very frustrated. If the user wants to synchronize the view, that's exactly what the Go To Source is for. With synchronization, it takes one click (on the multiview tab) to switch to the source. Using Go To Source, it only takes 2 clicks, and that could be changed to one gesture by using a shortcut key. The "overhead" of one click is a small price to pay for allowing the user to arrange things the way he wants.
Todd, What about 1-way synchronisation, from source to other views? We can have some listener for caret position change in XML editor view and make the node, which wrapps the current element in source view as current active node. So, navigator, mapper, property sheet and diagram itself will show this element. This is the way, how Java source editor workright right now(in NB55).
Todd, you MAY be right in your general thesis that user may want to control source and diagram independently. If so, we can leave functionality as is. Or, maybe we just add a Go To Diagram action on the source in order to provide symetrical functionality. Would you agree or object to that? However, your reply did not focus on the use case presented (i.e. user moves around in source and wishes to find the same position on diagram ). You focused on the Go To Source use case and did not address the Go To Diagram converse use case. So to summarize. Today we have what we can call 1 way manual positional synchronization - Diagram -> Source (i.e. Go To Source action ) This proposal was to introduce 2 way automatic positional synchronization You objected to this with some valid arguments. Synthesies 2 way manual positional synchronization Diagram to Source ( Go To Source action ) existing Source to Diagram ( Go To Diagram action) new How does that sound? We can add that functionality and leave all else as is. ---------------------------------------------------------- However .... "leaving all else as is" means living with one other unsynchronized effect, which you or others MAY object to, while not realizing its relation to this issue. Alexey's comments allude to this. Leaving all else as is, means that the source editor TODAY - DOES NOT set the active BPEL node. A consequence of this is that while in the BPEL source view, the property sheet and the navigator and the mapper are NOT in sync with the source view. They are in sync with the active BPEL node (as last set by either the navigator or the diagram). So, if you like that arrangement, then fine. Perhaps, navigator, mapper, and property sheet are irrelevant to someone working in source editor. I tend to think so, but I am not always representative of typical user. However, IF you do not like that arrangement, and IF you want the Mapper, Navigator and Property sheet to RESPOND to element seletion (i.e. positional changes in the source view) THEN the most direct way to do this would be to have the source view SET the active BPEL node. And, if we do that, then voila we have 2 way automatic sync b/t source and diagram ... becuase the diagram would respond automatically, as it does today to changes to the current active node. So you see, without other significant redesign, you have to choose your poison here. Either 2 way automatic postional sync OR manual sync (with no relationship b/t source view, editor and mapper). Which is it?
Listing this as Gavotte feature. Perhaps it will be closed as unnecessary, but let's continue analysis and resolve to either do something or close it.
In my work with schema editor I used GoToSchema and GoToDesign actions in schema source view. I found it very usefull and convenient feature. So I think we should have the same for BPEL source editor. What about synchronization of navigator and propertysheet with source editor - IMHO synchronized navigator gives usefull information about the place where I'm and property sheet - is an additional usefull tool. Moreover I think that Palette should be available for source editor too - in the same way like jsp editor.
It seems that there is general concensus that a Go To Design action on the Source will be very valuable. So I have created a more narrow feature issue 90268. All other features discussed in this thread are more controversial. So let's move this feature to Future, and focus on the simpler Go to Design action for this release. Changing this issue to Future and removing Gavotte whiteboard.
Fixed