Community
Participate
Working Groups
At the moment when launching or debugging an XSL file the user can choose an input XML from the workspace, externally or set a variable. There should also be an option for XML files which are currently open in the workbench. This allows users to browse to and edit whatever XML file they like and then run an XSL transform on it. I've already done some preliminary work implementing this. I've created the UI components in ResourceSelectionBock.java in xsl.debug.ui. I'm having some trouble finding an API to list the currently open files. I'm assuming it's technically possible.
I tracked down the API for getting the open files in the editor, it's PlatformUI.getWorkbench().getActiveWorkbenchWindow().getActivePage().getEditorReferences(); This returns an IEditorReference which gives the displayed filename. Getting the path is a little more tricky though. The IEditorReference class is generic and doesn't have any methods for directly getting the file path (since it might not even refer to a file) but getTitleToolTip() does happen to return a path (this is the text displayed if you mouseover an open file in the editor). Since we're looking on a very specific type resource (XML files) I think we can probably rely on this doing what we want.
You should use getEditor(false) - which should exist since the editors are open! Then you can use getAdapter(IFile.class) to get a reference to the IFile. This usually works!
Ah! Yes that works! This way is a lot better than relying on the tooltip. I need to use getEditor(true) because the only instantiated editor is the one currently open. This gives me an IEditorPart so I need to use getEditorInput to access the IEditorInput and then call getAdaptor to get the path.
Created attachment 127571 [details] Implmentation I have used the Eclipse "Create Patch" functionality before so let me know if it works. I've implemented the dialog with two caveats: -I called the button "Open Files" but that doesn't sit too well with me since it's more like a button to open files rather than a button to show which files are open. I don't know what term would be better understood. -At the moment it's hard coded to *.xml instead of the registered XML types. The UI dialog I used only supports one filter.
Thanks Stuart. It looks like this will fall underneath the 250 lines of code requirement so we don't need to send through IP for review. However, if you could update the patch, and add your name/company to the header files, that would be appreciated. I'm also since we are getting ready to move to Source Editing I'm going to have Nitin also review the patch. It looks low level enough and low risk enough.
Nitin can you review the patch. I've asked for some slight additions to headers, but other than that it looks alright.
No problem - where in the file should the author details go and in what format? Is there an example somewhere?
Add your name, company (if any), bug number, and brief description to the header under neath the Contributor section. An Example: Contributor: Doug Satchwell (Chase) - initial API and implementation Stuart Harper - bug 264788 - brief description Do that in each of the files you touched.
Also if the copyright date doesn't say 2009 please add 2009 like: 2008, 2009
You can see an example at http://dev.eclipse.org/viewcvs/index.cgi/sourceediting/plugins/org.eclipse.wst.xml.core/src/org/eclipse/wst/xml/core/internal/document/AttrImpl.java?root=WebTools_Project&view=markup . Assuming the comments are the only additional changes, the principle sounds alright to me. I would ask it be updated to check for a null result from the "((IFile) editorPart.getEditorInput().getAdapter(IFile.class))" statement, and collect the list of non-null paths accordingly. Many editors aren't restricted to working with resources and will return null in those situations, and you're talking to every open editor part. Also, any System.out.println statements should be commented out before they're committed. There are at least two in the ResourceSelectionBlock#openFileListResourceDialog() method. I'll update the flag when the "final" patch is attached.
Created attachment 127717 [details] Implementation MK II I've implemented the requested changes.
Created attachment 127760 [details] Updated patch to be Content-Type Aware Stuart I've updated your patch a bit to be content-type aware when it filters the dialog elements. Other than that the patch is as you had submitted it. Nitin can you review the current patch, and see if it's okay to commit.
Nitin, have you had a chance to review. I know we discussed adding the org.eclipse.core.xml.runtime content-type. But currently there are only *.xml, *.wsmsg, and *.fragx added there. I think the long term solution to the content type is to do away with the custom content type id that xml.core has, and use the platforms and extend it throughout wtp where necessary. So for now, I'd like to leave the patch as it stands, and address this when wtp in general addresses the issue. Probably after galileo.
((IFile) editorPart.getEditorInput().getAdapter(IFile.class)).getFullPath() in ResourceSelectionBlock would still have a possible NPE, plus you can ask the IPath for the filename extension directly instead of doing a string conversion. The custom type will not be removed as it's meant to be there for cases when the platform's describer, built on SAX and requiring proper syntax, won't recognize content but our own parser will. That's the only time it's meant to be used.
Created attachment 127960 [details] Updated patch to handle All XML Content Types and Null Paths This patch addresses the concerns raised about the content types from runtime.core.xml not being picked up, and the possibility of getFullPath() returning null.
Created attachment 127961 [details] Unit Tests for XMLContentType and bug 264788 Unit tests for the XMLContentType class added to xsl.core tests.
Created attachment 127978 [details] Updated to recurse all Sub Content-Types. This patch contains all of Stuart's changes, plus corrects the lookup of XML content Type file extensions so that it recursively gets all sub content types as well. This is in it's own class to make it easier to use and maintain. Unit tests have been updated as well.
Created attachment 127979 [details] Unit Tests for corresponding update2 patch
Approving, since I've made you jump through so many hoops already and the rest of it looks good. The NPE's on the return value of getAdapter(IFile.class), btw, not getFullPath(). I suspect I'll barge in and fix that if it ends up in CVS.
I've released the changes to head, along with the null check on the getAdaptor(IFile.class). I'll resolve once I see a build pass with this change in it.
Thanks, Stuart.
Thanks for the contribution Stuart. This should be available in head and with the next build.
mass update to 3.1 target due to movement from wtp incubator to wtp source editing lost the original milestones.
