Community
Participate
Working Groups
It would be nice to be able to provide content-assist in the href attribute that will list all stylesheets in the project.
Agreed.. This shouldn't be overly difficult as it just requires getting the files from the workspace, and creating the appropriate content assist objects.
Doug, question I have here, is how should we display the options for selection. A full path display could be quite long, and if we only show relative paths, this could be confusing. Maybe this would be a good place for Quick Assist support to bring up a dialog that lists the available stylesheets in the workspace, and allows the user to select from there?
Not sure what quick assist is, but I would be happy for the completions to show relative paths to xsl files in the project only (not workspace). To me it makes sense to use relative paths since that it what typically want to enter into the attribute. For instance, if you have an empty attribute and you press Ctrl+Space, you might get a choice of completions such as: lib1.xsl lib/lib2.xsl ../lib3.xsl If you then type '../' and then hit Ctrl+Space, you would see the content assist narrow to just: ../lib3.xsl whereas if you typed 'lib' you would get: lib1.xsl lib/lib2.xsl I think keeping it to project only is important since the other projects in the workspace can be in any location on the disk and are not necessarily relative to the current project.
Quick Assist, is when you press CTRL+1 and it brings up a list of items for fixing up problems or adding content. It's used quite a bit in the java editor. As for the content assistance, yeah, I think I can add some support for just the particular projects xsl files. I'll tentatively target this for 0.5m9 and see if I can get something going.
targeting for 1.0M2
I've hit a brain cramp on this. I can get all the projects in the workspace, but is there a way or a utility class that will take a filter and then return just the IFile's for that particular path. I believe there is a way to get a relative path, but is there a way to set it in relation to a an existing IPath or IFile?
Doing some more thinking on this, it might be better to do this through a dialog or short cut key, the brings up a dialog to insert the files in the workspace. I know there are already filters and dialogs setup for this in the Platform, so would be a matter of getting that file returned from the dialog. Also, I think that the content assistance display could get pretty messy when you have a large number of XSLT's that are in the workspace (i.e. Docbook project). Doug what do you think, would a Workspace dialog that has the filter by the content types like in Launching for the XML Input work in this situation?
When in doubt...do what the JDT does! I guess the equivalent in Java is when you type 'import' in the import declaraions section. If you type 'import' and then Ctrl + Space the JDT says 'No Default Proposals'. As soon as you type a letter however, and then press Ctrl+Space, it starts giving you completions and then narrows down as you type. I think thats probably the way to go.
(In reply to comment #8) > When in doubt...do what the JDT does! I guess the equivalent in Java is when > you type 'import' in the import declaraions section. > > If you type 'import' and then Ctrl + Space the JDT says 'No Default Proposals'. > As soon as you type a letter however, and then press Ctrl+Space, it starts > giving you completions and then narrows down as you type. > > I think thats probably the way to go. > There is a difference though between the way JDT does it and what the current Model for XSLT supports. JDT, they build a model of where all the Packages are stored, and index this on the hard drive. Where as with XSLT we have no model of all available stylsheets in the system. Which is why I was suggesting the dialog method. Also, JDT has a specific pattern that one can follow for the import as it's based on package name, XSL files don't have such a pattern, so would have to be based on directory name or at the minimum file name. Also what to do about possible external stylesheets hosted on URL's and referenced via httpp? Does XSL need a nature or facet that allows for this fine grain definition. I have some other model related questions and thoughts as well, but will take those to the mailing list to work out.
(In reply to comment #9) > There is a difference though between the way JDT does it and what the current > Model for XSLT supports. JDT, they build a model of where all the Packages > are stored, and index this on the hard drive. Where as with XSLT we have no > model of all available stylsheets in the system. There is a very good model we can use - the workspace root. It is a model of whats available in the workspace, and we can query that quickly enough ( via ResourcesPlugin.getWorkspace().getRoot().accept(new IResourceVisitor(){}) ). > Also, JDT has a specific > pattern that one can follow for the import as it's based on package name, XSL > files don't have such a pattern, so would have to be based on directory name or > at the minimum file name. I don't see very much difference...packages are pretty much the same as directories except they use a '.' instead of a '/' as a separator. Each class is a file - our files would be stylesheets. > Also what to do about possible external stylesheets > hosted on URL's and referenced via httpp? Does XSL need a nature or facet > that allows for this fine grain definition. I think we should take a straw poll on this one - I have never used, and have never come across anyone who uses - stylesheets that are anywhere except on the local filesystem. I'm not saying it has never happened, but I just don't think its very common, for obvious availability and performance reasons. I think as long as we allow people to specify http://whatever and for that not to be marked as a validation problem in the validator, its may be enough for all practical purposes? > I have some other model related questions and thoughts as well, but will take > those to the mailing list to work out. No problem.
There are several other things to consider as well when it comes to file inclusions. Is the path relative or absolute that is specified? If absolute should it be a valid URL (research says that this is highly dependent on the Processor being used.) According to the XSLT 1.0 specification for xsl:include: The xsl:include element has an href attribute whose value is a URI reference identifying the stylesheet to be included. A relative URI is resolved relative to the base URI of the xsl:include element. So this means that it needs to be a valid URI, which just including a path like: C:\ProgramFiles\somestylesheet.xsl or /home/someuser/somestylesheet.xsl Isn't correct for an absolute path. It should be, file:///C:/ProgramFiles/somestylesheet.xsl or file:///home/somesuser/somestylesheet.xsl. How that is constructed will depend on how where the user is going to deploy. I agree that most of the paths are going to be relative, and probably within the same project file, but in my case I have an xsl library that is kept in a separate project and deployed to a separate directory, so depending on my nesting, I could have a very long relative path, and it might be quicker to just reference via HREF instead of creating the relative path. The more I looked into this the more possibilities I came up with. Can you give me an example of the Query using the workspace resources. I'm not as good with the filesystem apis and core frameworks yet.
Actually, its even more complicated than that. You can set your own URIResolver class so you could resolve /home/someuser/somestylesheet.xsl to anywhere at all! In production systems, its rare to find absolute paths like file:///C:/Path/To/mystylesheet.xsl (its bad practice), so I think we should just cover what would be the majority of use cases: - paths are relative - all paths resolve to stylesheets that exist in the workspace - the default URIResolver is in place I think we should give content assistance for this situation only, because anything else is just too difficult. But we should also allow the user to write any valid URI into the href - be it file:///C:/Users/Documents/mystylesheet.xsl, http://example.com/mystylesheet.xsl or jar:file:/path_to_jar/file.jar!mystylesheet.xsl.
(In reply to comment #11) > The more I looked into this the more possibilities I came up with. Can you > give me an example of the Query using the workspace resources. I'm not as > good with the filesystem apis and core frameworks yet. If you like, if you check in a 'stub' of the content assistant, I can write the code that uses the workspace apis to create the content assist proposals.
(In reply to comment #13) > (In reply to comment #11) > > The more I looked into this the more possibilities I came up with. Can you > > give me an example of the Query using the workspace resources. I'm not as > > good with the filesystem apis and core frameworks yet. > > If you like, if you check in a 'stub' of the content assistant, I can write the > code that uses the workspace apis to create the content assist proposals. > All you need to do to implement content Assistance now since I refactored it a lot is the following: 1. Subclass AbstractXSLContentAssistRequest with a new class for the Import and Href Functionality. 2. In the new subclass, override the getCompletionProposals() 3. Add the appropriate check to the XSLContentAssistRequestFactory 4. Add some unit tests to test the proposals. Everything you need with examples is in org.eclipse.wst.xsl.ui.internal.contentassist
I'll have a go
In the ui.tests plugin, is there any particular reason to unzip a zip file as opposed to just using the expanded files in the same directory? In the core.tests plugins I used the expanded files - it saves having to remember to zip the file every time you make a change.
(In reply to comment #16) > In the ui.tests plugin, is there any particular reason to unzip a zip file as > opposed to just using the expanded files in the same directory? In the > core.tests plugins I used the expanded files - it saves having to remember to > zip the file every time you make a change. > Mainly because it hasn't been refactored to not use the ZIP file. It was modeled off the existing UI plugins from the XML.UI.Tests.
Assign
Have committed the code and built - all is fine
(In reply to comment #19) > Have committed the code and built - all is fine > Well...sorta... I would suspect that it would replace the entire HREF content with the proposal...also it doesn't seem to be narrowing the results. On the narrowing of the results, check to see what value is coming in for the matchString field. And to get it to replace the entire contents, the replacementBeginPosition should be getStartOffset() + 1. As it is right now, it is right now, the content is inserting the content into the proposal list instead of replacing the contents that are there already. If you want I can open another bug for this.
I'll take a look
marking as noteworthy
Have sorted those issues.
