Community
Participate
Working Groups
Build Identifier: Build id: 20100603-0907 Helios 3.5 RC3 You can create a simple xhtml filme. <html xmlns="http://www.w3.org/1999/xhtml" xmlns:ui="http://java.sun.com/jsf/facelets" xmlns:h="http://java.sun.com/jsf/html" xmlns:f="http://java.sun.com/jsf/core" xmlns:a4j="http://richfaces.org/a4j" xmlns:rich="http://richfaces.org/rich"> ...... <h:outputLabel .... if you press control + space you can see all the attributes like id, for, onblur, etc. <rich:panel ..... if you press control + space eclipse gives you "not Default Proposal (element rich:panel is unknow). This happens with icefaces, primefaces. If you rename the file extension to JSP, the content assist for attributes works again. I have tested in eclipse 3.5.2 and this behavior also happens with xhtml file, but it´s fine with jsp files. Reproducible: Always Steps to Reproduce: 1.create an xhtml file 2. put your favority JSP extended implementation like richfaces, primefaces, icefaces, whatever 3. try content assist for this elements and eclipse won´t be able to show the elements attributes.
Based on the website, RichFaces won't have full support for JSF 2.0 integration. Specifically, the version 3.0 limitations list says that "RichFaces 3.3.3 does not support JSF 2 built-in facelets (VDL)". The amount of support you get will also depend on how the taglib.xml files are configured for these libraries. If they do not encode specific tag information in their files, then there will be no design time support for these tags.
Well, this missing feature is the worst of all, because it’s almost impossible to remember elements attributes, thus, invalidating the use of the editor. I really don´t want to postpone the use of Java EE 6 support in Eclipse to future versions. We can´t use JBoss Tools, because (don´t ask me why) we are not allowed to. By the way, I take a look at eclipse configuration at: Preferences – JavaServer Faces Tools – Views – JSP TagRegistry I tried to activate the “introspecting tag resolver” but the problem was not resolved. What is intrigating me is why this feature works with jsp files and not for xhtml files? Why JSF base taglib displays corrects and others implementations not in xhtml files? I will contact JSF vendors, maybe I am lazy and missing some important information regards configuration. As I told in the past, JSP spoofing in xhtml resolved that problem, but today, the fix for circular dependence no more allows to go that way. When you say "future version", can I expect a service pack for helios to resolve this or this means the next Eclipse 3.7?
I have tested again with others libraries (Icefaces 2.0 beta, Richfaces 4.0 Alpha2 and PrimeFaces 2.0.3 final) and the problem persists. I have openned the tag library xml files from every distribution and it´s seems to be ok. In primefaces forum, I was told to await for the final release of Helios, so they don´t give me any advice. (In reply to comment #2) > Well, this missing feature is the worst of all, because it’s almost impossible > to remember elements attributes, thus, invalidating the use of the editor. I > really don´t want to postpone the use of Java EE 6 support in Eclipse to future > versions. We can´t use JBoss Tools, because (don´t ask me why) we are not > allowed to. > By the way, I take a look at eclipse configuration at: > Preferences – JavaServer Faces Tools – Views – JSP TagRegistry > I tried to activate the “introspecting tag resolver” but the problem was not > resolved. > What is intrigating me is why this feature works with jsp files and not for > xhtml files? > Why JSF base taglib displays corrects and others implementations not in xhtml > files? > I will contact JSF vendors, maybe I am lazy and missing some important > information regards configuration. As I told in the past, JSP spoofing in xhtml > resolved that problem, but today, the fix for circular dependence no more > allows to go that way. > When you say "future version", can I expect a service pack for helios to > resolve this or this means the next Eclipse 3.7?
Thanks, Flavio, for the input on this issue. We will test this out and comment on this bug.
(In reply to comment #3) > I have tested again with others libraries (Icefaces 2.0 beta, Richfaces 4.0 > Alpha2 and PrimeFaces 2.0.3 final) and the problem persists. I have openned the Are any of these open source? Can you post to a link to somewhere I could download one of these libs so I can take a look at the taglib.xml's? My suspicion is that they do not bother to explicitly declare their tags in these files. In that case, we can't provide help since we don't have the information we need.
Thank you for the reply :) Yes, they are all opensource. You can try that one (JSF 2 ready): http://primefaces.googlecode.com/files/primefaces-2.0.2.zip Inside the jar, the META-INF folder contains: primefaces-i.taglib.xml primefaces-p.taglib.xml primefaces-p.tld primefaces-i.tld ..... (In reply to comment #5) > (In reply to comment #3) > > I have tested again with others libraries (Icefaces 2.0 beta, Richfaces 4.0 > > Alpha2 and PrimeFaces 2.0.3 final) and the problem persists. I have openned the > Are any of these open source? Can you post to a link to somewhere I could > download one of these libs so I can take a look at the taglib.xml's? My > suspicion is that they do not bother to explicitly declare their tags in these > files. In that case, we can't provide help since we don't have the information > we need.
1 - Put Primefaces and JSF 2 library in the buildpath. 2 - create a XHTML file 3 - try to use content assistent for f, h, ui and p. (will not work) 4 - rename the same xhtml to jsp file. The content assist for namespace and elements attributes works fine. test.xhtml <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xmlns:f="http://java.sun.com/jsf/core" xmlns:h="http://java.sun.com/jsf/html" xmlns:ui="http://java.sun.com/jsf/facelets" xmlns:p="http://primefaces.prime.com.tr/ui"> <h:head></h:head> <h:body> <h:form> ... TRY CONTENT ASSISTENT HERE </h:form> </h:body> </html>
Created attachment 172300 [details] First Step ok This is the first step to test content assist with JSF 2 vendor library. This step is ok, the problem is for element attributes. See the next picture.
Created attachment 172301 [details] Second step - content assist for elements attributes - not ok This is where the problem rises. You can´t see content assist for any element attribute.
Hi, here two screenshot to illustrate the problem. The library used was Primefaces 2.0.2, but this problem also happens with Icefaces and Richfaces libraries. I hope this helps anyway.
Created attachment 172302 [details] xhtml renamed to jsp to show content assist behavior This is an xhtml file renamed to JSP. When you edit the file, the content assist works.
My guess would be that those facelet taglibs contain no information about the attributes. Only a list of tags/components. When you switch into JSP, a TLD file is used instead of the facelet taglib.xml, and TLDs do contain attribute information.
I made a similar posting (see Bug [314098]) And I agree with Flávio that there seems to be something wrong when using xhtml files. why is it problematic to accept also .xhtml files for the JSF content assist. For my understanding .xhtml files should have the same behavior like the .jsp files in a JEE Project. I am working with RichFaces - this is a common jsf library from JBoss. And I have problems with galileo. And as you can see in my blog post (describing a workaround) there are people who have the problem too. http://www-02.imixs.com/roller/ralphsjavablog/entry/eclipse_galileo_jsf_content_assist
I think what problematic is that library authors do not put any attributes information into taglib.xml file. It's not required for Facelets runtime to run the page, but the current tooling implementation has no means of finding what attributes a particular tag has.
(In reply to comment #14) > I think what problematic is that library authors do not put any attributes > information into taglib.xml file. It's not required for Facelets runtime to > run the page, but the current tooling implementation has no means of finding > what attributes a particular tag has. Correct. If you look at prime faces as an example, here's an example of a tag definition for the accordian panel: <tag> <tag-name>accordionPanel</tag-name> <component> <component-type>org.primefaces.component.AccordionPanel</component-type> <renderer-type>org.primefaces.component.AccordionPanelRenderer</renderer-type> </component> </tag> So they have not provided us any information about the attributes. Compare this to the tag libs that are provided for the built-in h:outputText tag: <tag> <!-- snip description for clarity --> <tag-name>outputText</tag-name> <component> <component-type>javax.faces.HtmlOutputText</component-type> <renderer-type>javax.faces.Text</renderer-type> </component> <attribute> <description> Converter instance registered with this component. </description> <name>converter</name> <required>false</required> <type>javax.faces.convert.Converter</type> </attribute> <attribute> <description> The component identifier for this component. This value must be unique within the closest parent component that is a naming container. </description> <name>id</name> <required>false</required> <type>java.lang.String</type> </attribute> <!-- snip remaining attributes for clarity --> </tag>
Thanks! This leads me to think that Primefaces and others JSF vendors are relying in some IDE voodoo magic to show element attributes for missing information in their tag definition (probably accessing missing information in JSP taglib). I don’t think is fair to ask for Eclipse Team to make such a thing. JBoss Tools and Netbeans are able to handle this problem, but I think that is the responsibility of the developer to guarantee library compatibility across IDE´s, since we are talking about specification. I will wait for Helios final release (it´s near!!!) to gentle ask JSF vendors for the completion of their taglib declaration. I also understand their position (I’m wondering), because it’s easy to main attribute information in one file then two. Since “JSP spoofing” for XHTML don’t work anymore in Helios, maybe this will be forcing JSF vendors do fix this issue in their taglibs, meanwhile, a lot of people like me will have to face this problem alone. Thanks again!
This is the answer I received in Primefaces Forum, when I asked for taglib completion: Re: primefaces-p.taglib.xml missing attribute declaration by Oleg » Tue Jun 22, 2010 9:04 am Hello. It's not nessesary because attributes should be extracted via Java reflection (according to the spec.). Sadly, but there isn't really good IDE that does it completely The code autocompletion is due to TLDs (in classpath) at the moment.PrimeFaces 2.0.2, Mojarra 2.0.2, JBoss 5.1.x, Weblogic 10.x, GlassFish v2/v3Oleg Posts: 685 Joined: Fri Oct 02, 2009 7:41 am Location: Russia, Siberia => Germany, Black Forest Source http://primefaces.prime.com.tr/forum/viewtopic.php?f=3&t=2887
It's not technically necessary, but it will go a long way towards making it easier for IDEs to support JSF2 libraries. Both files, taglib.xml and TLD, are most likely automatically generated during libraries build process. It shouldn't be too hard for library vendor to augment taglib.xml with attributes. There is no maintenance cost associated with that, just one extra generation step during the build/packaging.
> It's not nessesary because attributes should be extracted via Java reflection > (according to the spec.). Sadly, but there isn't really good IDE that does it We have tried this in the past and had mixed results. Performance can become an issue if the number of tags is large. Note that is also possible to only specify a tag factory (not even the tags), in which case it is even more difficult to extract that information. In the future we will probably provide an extension through which additional information about tags can be contributed by adopters or end-users. We have a metadata framework that does this for other information but we couldn't use it in this release for that purpose because it would create a circular dependency.
Despite this "problem", I am happy with Eclipse 3.6 (Java EE 6). As I can see, the next 3.7 release will polish even more the IDE. Thanks you guys!
(In reply to comment #20) > Despite this "problem", I am happy with Eclipse 3.6 (Java EE 6). > As I can see, the next 3.7 release will polish even more the IDE. > Thanks you guys! Appreciate your feedback and thanks for your participation.
I think Eclipse is the cat's meow, but using Primefaces with Eclipse is a litter box without content assist. I assume that getting Primefaces to fill in the taglib descriptor is the shortest path to solving this problem. To that end, a bug has been opened, which Mr. Primefaces suggests will be addressed if it can get enough votes. http://code.google.com/p/primefaces/issues/detail?id=1176 Looks like a half dozen votes will get it on the radar. Go get 'em. Make me happy.
(In reply to comment #22) > I think Eclipse is the cat's meow, but using Primefaces with Eclipse is a > litter box without content assist. > > I assume that getting Primefaces to fill in the taglib descriptor is the > shortest path to solving this problem. To that end, a bug has been opened, > which Mr. Primefaces suggests will be addressed if it can get enough votes. > > http://code.google.com/p/primefaces/issues/detail?id=1176 > > Looks like a half dozen votes will get it on the radar. Go get 'em. Make me > happy. Here: http://cagataycivici.wordpress.com/2010/08/31/primefaces-support-in-eclipse-helios/ They have added the metadata to the taglib, it's working now
Today, no IDE has the hability to scan for @ManagedBean. JBoss Tools "doesn´t" like @ManagedBean, so they only scan por @Named (CDI replacement for JSF managedBeans), It would be very nice to have annotation scanning for @ManagedBean in Eclipse. Can we expect this in the next release? If the performance is a problem, maybe we could configure in the project the packages to scan for annotation types. I known this is not the best solution, but helps a lot. If the answer is positive, I am ready to start testing as soon as possible :)
> Today, no IDE has the hability to scan for @ManagedBean. Not quite true. RAD supports @ManagedBean annotations.
(In reply to comment #24) > Today, no IDE has the hability to scan for @ManagedBean. > > JBoss Tools "doesn´t" like @ManagedBean, so they only scan por @Named (CDI > replacement for JSF managedBeans), > > It would be very nice to have annotation scanning for @ManagedBean in Eclipse. > > Can we expect this in the next release? > > If the performance is a problem, maybe we could configure in the project the > packages to scan for annotation types. I known this is not the best solution, > but helps a lot. > > If the answer is positive, I am ready to start testing as soon as possible :) This is under consideration for the Indigo release. We will confirm in the M3 timeframe. Thanks for your interest and volunteering to test the feature.
I'am working with 3.6. When i open my file the testfile.xhtml using "Open With" -> "JSP Editor": autompletion is not working. If I rename the same file to testfile.jsp and open it also with "Open With" -> "JSP Editor": autocompletion works. Why did the editor get the information when the file has the jsp extension? If i open the same workspace with Eclipse 3.5.2.R35x it works in both cases. See also (Open xhtml files with JSP editor): http://www.mojavelinux.com/blog/archives/2006/12/facelets_tag_completion_in_eclipse/
See comment #12 by Yury. When you are editing an XHTML file, the source of truth about tags and attributes is a *.taglib.xml file, when you start editing a JSP, the source of truth is a TLD. Please check your library's tag descriptors to see if the attributes are listed only in the TLD - if this is the case, then this is why you are experiencing this.
I have also the same problem with .xhtml files. It was a problem in eclipse 3.5 and many people wrote blogs how to fix this by adding the right content type for xhtml files. Now with Eclipse 3.6 the same problem again. And it seems to me that the normal workarounds did not work. I don't think that we all are trying to develop exotic web projects? In my case I am working on a maven based JEE6 Project using m2Plugin, RichRaces and running on Glassfish. I think this is an typical szenario for many JEE developers. JSF/Faclet Pages named *.xhtml did not support code completion in Eclipse 3.6. Renaming the file in *.jsp code completion works. What should we do to tell Eclipse handling .xhtml files like .jsp files? Pleas do not tell us that we have to check the tag descriptors in our libraries. There must be a trick to tell Eclipse that a .xhml file is the same as a *.jsp file!
>>What should we do to tell Eclipse handling .xhtml files like .jsp files? Folks, is it possible ? at first sight it looks like a configuration thing... It is really important... Thanks,
(In reply to comment #30) > >>What should we do to tell Eclipse handling .xhtml files like .jsp files? > > Folks, is it possible ? at first sight it looks like a configuration thing... > It is really important... > > Thanks, For Juno, we will investigate a mechanism for using information from TLD as a fallback mechanism. See comment 19.
It has been explained several times in this bug report why there is a difference. When dealing with JSF 2.0 and *.taglib.xml descriptors, a different mechanism is used to determine the available attributes. If the author of such a library has not provided the attribute information, it is not correct to assume that any available TLD is appropriate to describe the tag library - there could be good reason that a TLD and *.taglib.xml files describe different attributes and it would be wrong for us to assume these two descriptor methods are interchangeable. That said, there is no simple solution that can address this anyway; a factory has been chosen to provide the content model before element information is requested. There is no way to determine the validity of a factory based on what arbitrary attribute information it is provided. That is, the factory can not be determined to be invalid at the point where the factory is registered, and when the factory is asked to provide element information, it is too late to "swap in" another factory based on some heuristic that decides which is more appropriate. PrimeFaces 2.2.1 and RichFaces 4.0.0 now have attribute definitions in their *.taglib.xml descriptors; I doubt this was done for the fun of it, the definitions should have been there all along and the authors have rectified the problem. I believe this to be the correct resolution for this issue; library authors need to provide the expected attribute definitions with their libraries.
Closing this bug. Please reopen if there are other suggestions that we should consider.
