Community
Participate
Working Groups
In the xpath view, it would be nice to be able to switch to a different active editor (e.g. a JSP), but still be able to type an xpath and evaluate it against the last active XML file.
(In reply to comment #0) > In the xpath view, it would be nice to be able to switch to a different active > editor (e.g. a JSP), but still be able to type an xpath and evaluate it against > the last active XML file. > Yep. We probably need to enhance the view to allow selection of either the current open editor, or a particular XML file. This probably should be selectable based on which of the tabs is open.
Assigning inbox items to triaged since these have all be triaged.
Since I'm working enhancements to the XPath view, question I have is how do we want to enable this. Do we want to add a menu item, or do we add a drop down selection box. Another option is that we could add to the View Menu the ability to select which file. I recently added with bug 261588 the ability to edit the namespaces for the active editors file. The old XPathNavigator used a drop down selection box to set the Active Context that the expression went against. Looking for input and ideas.
1. As a start, it would be good just to not clear the view out when we move away to a non-XML file. 2. Then we could add a 'link with editor' icon on the toolbar that toggles on/off the ability to refresh the view based on the active editor instead of having it always on. 3. After that, we can add a browse button and a drop down box that has a history of recently active XML files like the old xpath navigator had. No.1 is a quick hit if time is limited. What do you think?
(In reply to comment #4) > 1. As a start, it would be good just to not clear the view out when we move > away to a non-XML file. Right now it is always looking at the activeEditor. We could tie the tabs to a ModelID and have it work off that information. The main concern is how do you tell the view when you are done with a particular file. We could potentionally start to create memory leaks if we don't ever release the models? Some of the XML files can get quite large. If it is not the active editor do we just open the file, run the xpath against it and then close it again? > > 2. Then we could add a 'link with editor' icon on the toolbar that toggles > on/off the ability to refresh the view based on the active editor instead of > having it always on. There is already a Link With Editor icon on the tool bar. I've never used it though as the current view always goes with the activeEditor. > > 3. After that, we can add a browse button and a drop down box that has a > history of recently active XML files like the old xpath navigator had. > > No.1 is a quick hit if time is limited. What do you think? We still have the code from the XPathNavigator so we have a starting point.
You're right, the link with editor doesn't seem to do anything at the moment. It needs to be hooked up. We should restrict to only those files open in an editor. That way we always get the model from the editor and wouldn't have to worry about memory leaks. So maybe we should have a drop-down of all open XML files and: - when the 'link with editor' toggle is on, the drop down is disabled and just shows you the name of the file it is using. - when the link with editor' toggle is off, the drop down is enabled and you can choose from any file open in an editor
(In reply to comment #6) > You're right, the link with editor doesn't seem to do anything at the moment. > It needs to be hooked up. > > We should restrict to only those files open in an editor. That way we always > get the model from the editor and wouldn't have to worry about memory leaks. > > So maybe we should have a drop-down of all open XML files and: > > - when the 'link with editor' toggle is on, the drop down is disabled and just > shows you the name of the file it is using. > - when the link with editor' toggle is off, the drop down is enabled and you > can choose from any file open in an editor The old XPathNavigator has some code that we can migrate over. Feel like getting your hands dirty again Doug? It's been a while. You'll want the latest code from Head.
Are there use cases for the view not to be operating with the active editor?
(In reply to comment #8) > Are there use cases for the view not to be operating with the active editor? Yes plenty. It is quite common to be writing an XPath statement that needs to work against a sample XML document, while working with the XSLT editor. The XML input may be too large to open within it's own editor, so it may be more beneficial to have it work on it at a document level. Retargeting for 3.2M6 just because I know I'm running short on time over the next several weeks.
Marking as Helpwanted, will gladly take any patches to make this happen.
Moving to the XPath component out of XSL.
