Community
Participate
Working Groups
When using the 'Page' tool from the palette to create a navigation rule, the file picker filters the files with a set of 4 known file extensions (jsp, jsv, jtpl, jspx). Our JSF files use a propietary format with a different file extension so we are unable to select them from the dialog. ( see CreateNodeCommand.selectJSPPage() ) NOTE: drag/drop of files to the navigation canvas doesn't make the same assumption and allows the user to drop any file type to create a navigation rule. That is our current workaround. Also a similar check is made when double clicking on a page. The OpenEditorCommand makes a call to WebrootUtil.isValidWebFile(resource) and if it returns false it shows an error message instead of opening the editor. We have currently have no workaround for this. Possible fixes: 1. Add some mechanism to declare additional file extensions (or contentTypes) that are valid 'web files'. (from extension point and a preference page). 2. Remove the 'web file' file extension checks completely. 3. Other?
Hi Jean, Please review this bug and give your feedback. -Raghu
JSP file has four standard extensions: *.jsp, *.jspx, *.jsw, *.jsv. If you want to add another file extension, you need to configure the application server and web.xml file (create a <jsp-property-group> and add <url-pattern> tag for each extension). I think it is better for WTP (not JSF) to provide an extension mechanism for user to define JSP file extension, so that user can use that extension point to define their own JSP file extension. A quick fix will be this: 1. User can still drag and drop any type of files from navigator to the navigation canvas, so we will not change to restriction of selecting a JSP file from the dialog; 2. For double click to open the page, we will not check the file extension, but will use default editor to open the file. That makes sense because any type of file can use its own default editor to open it.
Hi Jean, > I think it is better for WTP (not JSF) to provide an extension mechanism for > user to define JSP file extension, so that user can use that extension point Actually I think there is already a mechanism for that the user can set called "Content Types". The user can set it using Windows->Preferences->General->Content Types. Perhaps we could then replace or modify the problem method WebrootUtil.isValidWebFile that Eric has identified with code like this: IContentTypeManager typeManager = Platform.getContentTypeManager(); IContentType jspContentType = typeManager.getContentType("org.eclipse.jst.jsp.core.jspsource"); if (jspContentType != null && jspContentType.isAssociatedWith(file.getName())) { return true; } Would this solve some or all of the problem?
Very good suggestion! Thank you! I made a small change to your code, using getFileSpecs(IContentType.FILE_EXTENSION_SPEC) to get JSP file extensions. So creating a page from palette also works. Hope it solves all the problem. Related files: WebrootUtil.java in facesconfig.common plugin CreateNodeCommand.java in facesconfig.ui plugin
Codes are checked in the Eclipse CVS.
Closing as part of mass query to clean up old resolved bugs in untargetted milestones.
(In reply to comment #4) After upgrading to eclipse 3.3/WTP 2.0, I'm reviewing what was fixed for this bug and I think the solution is still flawed. You are still assuming that the JSF view files are some flavor of JSP. In our case we use a proprietary XML format for defining the JSF component tree that is not related to JSP at all. The JSF spec does not say that the views have to be JSP, so I don't think the Navigation editor should apply that restriction. While I can add our file extension to the set of JSP Content Types, that introduces additional side effects that I am not really comfortable with. (For example, the JSP Editor becomes associated with our file extension). I think the same issue would apply for people using facelets for their views. A facelet developer may use a .xhtml file extension (or any other arbitrary file extension) for the views. In the current Navigation editor, the file picker does not let them select non-JSP files.
The JSP component would be happy to help in the content type determination, but there's a limitation with content type describers not having awareness of resources and paths when asked to describe a stream. I opened bug 183309 to deal with encoding support, but you might want to glom onto it more.
Triaged for 3.0
*** Bug 151526 has been marked as a duplicate of this bug. ***
Eric: do you use your own view handler implementation to support your non-JSP views? Part of the framework is creating what I'm calling a "View Definition Adapter" that can be used to adapt your definition language (ideally based on XML) to the framework. I have changed the action list in the properties for a navigation rule to use this. I have changed the filter on the dialog so it doesn't filter by extension on files any longer. Since the DnD from the navigator has no such restriction, it doesn't makes sense in the dialog. Also added the ResourceComparator to sort the tree the same as the navigator. Change is attached in patch.
Created attachment 92495 [details] Fixes the dialog filter problem and adds better tree sorting.
(In reply to comment #11) > Eric: do you use your own view handler implementation to support your non-JSP > views? Yes, we have our own view handler.
> Yes, we have our own view handler. You may be interested in looking at the new Facelet support plugins that are currently in the incubator. They aren't released yet and aren't quite ready for prime-time, but they exist in CVS under /cvsroot/webtools in the "incubator" top-level folder. Note that this tooling relies on framework changes in our core tools that is intended to be used (post-3.0 from an API perspective) by alternative view handlers besides just Facelets. If you're interested in tracking progress on Facelets you can CC on https://bugs.eclipse.org/bugs/show_bug.cgi?id=192393. If you think you can benefit from this sort of framework for your own technology, let me know and we can launch a new bug to discuss. Are you going to be at EclipseCon next week by any chance?
Fix committed to HEAD.
Sorry, I won't be at EclipseCon. I'll definately look into the facelet support plugins when I get some free time.
Verify and close in 3.0 label 20080616152118. Criteria: - drag and drop of both JSPX (in the jsp content type) and HTML (not in the jsp content type) files works into navigation pane of faces-config editor (as before). - using the Page feature to find documents also shows both JSP and XHTML files. - the Page dialog uses the same tree sort order as the navigator. - double-click on either the JSPX or the HTML page from the navigation rule editor canvas opens the corresponding editor.
