Community
Participate
Working Groups
This is very important feature for all people using facelets now. Workaroung like .jspx are very ugly, simple .xhtml editor, with valid xml support is minimum.
Planned for 3.0
Mariusz, can you expand on what is needed here so that we can get an idea of what is required? Also, if you have simple workarounds that would make life easier for facelet users in the interim and that you can post as patches, we might be able to consider them for a 2.x maintenance release if we have one.
Is possible to open .xhtml files with XML editor (not default HTML editor) - I think this can help. Workaround is described here: http://www.mojavelinux.com/blog/archives/2006/12/facelets_tag_completion_in_eclipse/ Eclipse have autocomplete support for facelets like (xml like) tags (ex: xmlns:h="http://java.sun.com/jsf/html"). This work very well with Eclipse JSPX editor. But this solution require to change suffix of files (from .xhtml to .jspx). I think this should be more flexible. Maybe is possible to simply configure eclipse to map .xhtml files with JSPX Editor? This is not perfect solution, but should work and help. All what is needed to make JSP editor more flexible and add option to open .xhtml files in it.
Ok, I tested this and eclipse is configurable enough. But this still require ugly jsp:root and ?xml in header.
Btw, eclipse have support for autocomplete in xml files with xmlns stuff. Why this not working, when I open .xhtml file in XML Editor? The syntax look very similar. For example, code completiton work for: http://fisheye.jboss.com/browse/~raw,r=1.6/JBoss/jboss-seam/examples/ui/resources/WEB-INF/components.xml But is not working for file like this: http://fisheye.jboss.com/browse/JBoss/jboss-seam/examples/booking/view/display.xhtml?r=1.2 even if I add xml header. What is wrong?
Thanks for the additional feedback. (In reply to comment #5) > Btw, eclipse have support for autocomplete in xml files with xmlns stuff. Why > this not working, when I open .xhtml file in XML Editor? The syntax look very Where are you trying to use autocomplete in these files?
(In reply to comment #6) > (In reply to comment #5) > Where are you trying to use autocomplete in these files? For example for f:outputText (outputText should be visible in dropdown selection list). Probably this is related to missed xml schema?
In JSP editor completation work, because this use TLD definition for JSP tags (not facelets schema directly).
We will review this as part of support for Facelets in 3.0
Hi Raghu, As I guess all technology is there already (works for JSP infrastructure), would it be an option to include it earlier, in an incremental build already? Like 2.1 or 2.2? Facelets is used by a growing numer of people, JSP by a diminishing nr... It would be a pitty Eclipse would miss this momentum ;-) -Wolf (In reply to comment #1) > Planned for 3.0 >
(In reply to comment #10) > Hi Raghu, > As I guess all technology is there already (works for JSP infrastructure), > would it be an option to include it earlier, in an incremental build already? > Like 2.1 or 2.2? > Facelets is used by a growing numer of people, JSP by a diminishing nr... > It would be a pitty Eclipse would miss this momentum ;-) > -Wolf > (In reply to comment #1) > > Planned for 3.0 > > The next release on the 2.0 stream is a maintenance release 2.0.1 scheduled for Sept 28,07. We can't add new features in thsi release. That said, if there are simple bugs that block the adoption of facelets, we will consider them. We will have a better picture in the coming weeks. I would like to encourage you to help us define the support for Facelets.
I'd b happy to Raghu! There are a few things: - autocompletion for facelets (= the ui: taglib) - when open open a page in Eclipse's Web Page editor, that it understands these tags as well. E.g. if you specify the facelets template used, and a CSS is defined in this template (= typically one of the things you'd declare in the templat to avoid having to reference it from every other page), that Eclipse digs up this reference and we can see it's effect in the preview Pane. As the other elements from he template. - perhaps more a JSF than a Facelet issue: currently, Eclipse CAN do auocompletion AND shows the JSF elements ... but only of you put a wrapping jsp element around the page and declare the ns(-es) in the jsp root element. With facelets, you would want to avoid the JSP alltogether and use, as someone else stated here, plain XHTML pages for jsf + facelets editing. That's what I meant with quick wins; Eclipse CAN already do it, but it misses some inside content-sensitive coupling that disables this currently. So now, I add and remove the JSP wrapper elements every time again... (I know) I think these are the majorissues :-) If others feel smth is missing - please add! In order of importance, for me at least: 3rd pt > 1st pt > 2nd pt --> 1 and 3 in an incremental relase, if it can be done without too much trouble, would be awesome!! -Wolf (In reply to comment #11) > (In reply to comment #10) > > Hi Raghu, > > As I guess all technology is there already (works for JSP infrastructure), > > would it be an option to include it earlier, in an incremental build already? > > Like 2.1 or 2.2? > > Facelets is used by a growing numer of people, JSP by a diminishing nr... > > It would be a pitty Eclipse would miss this momentum ;-) > > -Wolf > > (In reply to comment #1) > > > Planned for 3.0 > > > > > The next release on the 2.0 stream is a maintenance release 2.0.1 scheduled for > Sept 28,07. We can't add new features in thsi release. That said, if there are > simple bugs that block the adoption of facelets, we will consider them. We will > have a better picture in the coming weeks. I would like to encourage you to > help us define the support for Facelets. >
Created attachment 76000 [details] Experimental changes to ease use of xhtml files I have made some small, low-risk changes here to make it easier to use xhtml files in JSF development: - xhtml has been added as an extension that the JSFFileUrl handler recognizes. This makes it possible to deploy an XHTML file the same as a JSPX file. The .xhtml ext still needs to be added to the servlet-mapping's available for the Faces Servlet (we will prob need to add an option for this to the new project wizard). - in the Web Editor, we now properly handle prefix lookup based on xmlns for both basic palette drops and their template contents (i.e. the outputText's being dropped due to template in an h:panelGrid). This should allow basic visual editing support for those tags that have TLD's in the classpath using XHTML. These are far from a final solution, however, a fix of this scale is possible for 2.0.1 with further follow-ons in 3.0. I would appreciate if anyone who has time would try out this patch and look for additional issues so we can see if it is worth applying for 2.0.1.
> element around the page and declare the ns(-es) in the jsp root element. With > facelets, you would want to avoid the JSP alltogether and use, as someone > else stated here, plain XHTML pages for jsf + facelets editing. I have started to work toward increasing usability in this area. One problem with the XHTML route is that while it is true that we have SSE support for ns-based lookup of tags, facelets don't seem to define their entities this way. Instead, they have created yet another non-standard tag definition language in the form of the taglib.xml (http://java.sun.com/dtd/facelet-taglib_1_0.dtd) file. The facelet taglib is much less tool-friendly than the JSP taglib. Unlike a TLD which provides parsible meta-data about each tag, it's required attributes and so on, all of the facelet taglib's I have looked at are of the form: facelet-taglib> <library-class>com.sun.facelets.tag.jstl.core.JstlCoreLibrary</library-class> </facelet-taglib> I have not looked at the source for these files yet, but it remains to be seen if there is even a way to query the library object to see what tags are valid (and therefore provide a tag set with which to populate the content-assist feature). Two routes to supporting facelet native tags seem obvious: 1) In most cases, a component library will probably come with a TLD so that it can be used in JSP mode. In this case, we can query the tld for the basic meta-data we need. 2) Failing the above, we can try to use additional meta-data provided by the component vendor/provider to identify this basic information. 3) Failing this, we probably won't be able to support content-assist or validation of tags in XHTML mode. I am open to other interpretations/solutions and welcome suggestions.
There are various possibilities to define a facelet tag library 1) using a com.sun.facelets.tag.TagLibrary interface implementing class. For those ones, you can't query them, AFAIK, for list of tags. It has only methods in the forms boolean containsFunction(...) containsTagHandler(...). Those are mainly used by the standard Facelets tag library, you could hardcode the list of tags for the standard Facelets Tags (ui, core, etc) 2) By manually expliciting in tag libray file the list of tags. Each tags can be defined various ways: 2.a) Using a com.sun.facelets.tag.TagHandler. It has same problem as point 1, no informations on attributes (required or not) 2.b) Using a Component/Converter/Validator. From the Component Type, you can get the Component Class. From the class you can inspect the getters/setter to get a list of properties (Facelets will use getAttribute().put(name,value) on Component which is a special map which can use getter/setters if available). This is, unfortunately, only a hint as there may be attributes used by component that don't have specific getters/setters (thought they generally have those as they make components easier to maintain). Same applies for validator/converter 2.c) Using a source, which is a tag that will be replaced by content of an xhtml file. The attribute will be passed as parameter variables to included file. There is no way i know of to list them. I agree with your suggestion about using .tld if available, it's most of the time more verbose than facelets tag, but longer to develop a component using that:) As for the validation of tag, it may be possible, from the com.sun.facelets.tag.TagLibrary to know if a user entered tag is valid, but it's impossible to list all valid name :( For TagHandler classes, it's impossible to test i think them because those are designed to be used at run time. And for UIComponents, you can still provide autocompletion based on properties not coming from UIComponent, + general properties available in all JSF Components. But again it's only hints, as it's not restrictive. The good news is that, if i add attributes not existing in UIComponent, Facelets will apply them to uicomponent using map, uicomponent will not care, and it will work perfectly (it will just be useless)
(In reply to comment #14) > The facelet taglib is much less tool-friendly than the JSP taglib. Absolutely correct. This is a gripe for "production environment". The advantages exist while one is developing the facelets components. > Unlike a > TLD which provides parsible meta-data about each tag, it's required attributes > and so on, all of the facelet taglib's I have looked at are of the form: > > facelet-taglib> > <library-class>com.sun.facelets.tag.jstl.core.JstlCoreLibrary</library-class> > </facelet-taglib> A lot of taglibs are more verbose, but still the info about attributes ARE missing. > I have not looked at the source for these files yet, but it remains to be seen > if there is even a way to query the library object to see what tags are valid > (and therefore provide a tag set with which to populate the content-assist > feature). Basically a Meta-data class... > Two routes to supporting facelet native tags seem obvious: > > 1) In most cases, a component library will probably come with a TLD so that it > can be used in JSP mode. In this case, we can query the tld for the basic > meta-data we need. This would mimick the behaviour of the one plugin that currently provides a good support for facelets: Exadel. Therefor I could imagine this to be a good route until JSF (and following Facelets) finally finishes its tool-friendly Meta-Data JSR. True, for the ambitious Facelets component-developer this might cause an overhead, BUT as the documentation needs to be done in some way... it should be possible to generate it in two formats: a TLD for the tooling and some HTML-version (or PDF via FOP...) for the "human" reader. In this way the overhead for the component developer is reduced and his users (that then use WTP) are more happy. > 2) Failing the above, we can try to use additional meta-data provided by the > component vendor/provider to identify this basic information. Define yet another meta-data provider? Makes sense only if it is fed into the above mentioned JSR... > 3) Failing this, we probably won't be able to support content-assist or > validation of tags in XHTML mode. Which would be a pity... but is understandeable. As I said above my vote is: use a tld that has to be provided by the component-developer... or some third-party. All you would have to provide for this is some way to map a namespace-definition to a meta-data-tld file.
(In reply to comment #13) > I would appreciate if anyone who has > time would try out this patch and look for additional issues so we can see if > it is worth applying for 2.0.1. I have just tried the patch. I applied it against org.eclipse.jst.jsf.core_1.0.0.v20070619.jar and org.eclipse.jst.pagedesigner_1.0.0.v20070621.jar I opened it in the web page editor, and it does seem to help a little, but not much. I am getting attributes on h: and f: (JSF Core/Html) only. The palette shows many libraries, but the properties window doesn't seem to get information from the same libraries. The top of one of my files: <!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:c="http://java.sun.com/jstl/core" xmlns:f="http://java.sun.com/jsf/core" xmlns:fn="http://java.sun.com/jsp/jstl/functions" xmlns:h="http://java.sun.com/jsf/html" xmlns:jdt="http://www.jenia.org/jsf/dataTools" xmlns:t="http://myfaces.apache.org/tomahawk" xmlns:ui="http://java.sun.com/jsf/facelets" xmlns:tr="http://myfaces.apache.org/trinidad" xmlns:trh="http://myfaces.apache.org/trinidad/html" xmlns:ts="http://myfaces.apache.org/sandbox" xmlns:s="http://jboss.com/products/seam/taglib">
Still, that's very good news. I perfectly sympathise with a gradual approach. Shipping what is available AND works, even while being limited in ways, is much better than having nothing. I experienced no bugs in he patch. (just the limitations mentioned above) & @Camreon: Keep up the great work!! (In reply to comment #17) > (In reply to comment #13) > > I would appreciate if anyone who has > > time would try out this patch and look for additional issues so we can see if > > it is worth applying for 2.0.1. > > I have just tried the patch. I applied it against > > org.eclipse.jst.jsf.core_1.0.0.v20070619.jar > > and > > org.eclipse.jst.pagedesigner_1.0.0.v20070621.jar > > I opened it in the web page editor, and it does seem to help a little, but not > much. I am getting attributes on h: and f: (JSF Core/Html) only. The palette > shows many libraries, but the properties window doesn't seem to get information > from the same libraries. > > The top of one of my files: > <!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:c="http://java.sun.com/jstl/core" > xmlns:f="http://java.sun.com/jsf/core" > xmlns:fn="http://java.sun.com/jsp/jstl/functions" > xmlns:h="http://java.sun.com/jsf/html" > xmlns:jdt="http://www.jenia.org/jsf/dataTools" > xmlns:t="http://myfaces.apache.org/tomahawk" > xmlns:ui="http://java.sun.com/jsf/facelets" > xmlns:tr="http://myfaces.apache.org/trinidad" > xmlns:trh="http://myfaces.apache.org/trinidad/html" > xmlns:ts="http://myfaces.apache.org/sandbox" > xmlns:s="http://jboss.com/products/seam/taglib"> >
> much. I am getting attributes on h: and f: (JSF Core/Html) only. The palette > shows many libraries, but the properties window doesn't seem to get > information from the same libraries. Rendering and property view information is dependent on a combination of tag meta-data and tag information. In the case of h and f, there is default meta-data present out of the box; not so with other tags. If meta-data is not present a more generic property page is created based the tag's TLD information. Unfortunately, the TLD manager doesn't bother to provide this for files that it doesn't think are JSPs.
I would like to benefit from this patch but have no idea how to do this. Tried patching it to the jar-files... Tried checking out the webtools in CVS... To bad but I have no experience with these issues. However I would like the code-completion functionality for Facelets (in .xhtml files) to work in Eclipse Europa. Would somebody be so kind as to send me the patched jar files needed? Or provide an URL as to where I can find these jar's? Thanks and greetings, Timothy
Hi Timothy, A couple of notes: 1) The patch I have provided is simply a starting point and does not solve all of the issues related to using xhtml-style facelet pages. 2) The patched code should be available in an upcoming milestone build of WTP. Having said that, if you don't want to wait to try it, you can try the following: 1) In a (preferably empty) workspace, go to Windows->Show View->Other..->CVS Repositories. 2) In the CVS Repositories view, right-click and New..->Repository Location. In the wizard, use the following connection settings: Host: dev.eclipse.org Repository Path: /cvsroot/webtools User: anonymous Password: your-email@address.com Connection type: pserver 3) Hit Finish and after the connection is validated, you should get a new tree element in the CVS Repositories view for ":pserver:anonymous@dev.eclipse.org:/cvsroot/webtools. 4) Expand the tree to: HEAD/org.eclipse.jsf/components/jsf/plugins 5) With Ctrl depressed, select: org.eclipse.jst.jsf.core org.eclipse.jst.pagedesigner and then right-click, Check Out. You should now (after you finish sync to the server) have these two plugins in your workspace. 6) Right-click on one of the plugin projects and go Team->Apply Patch.... Supply the attached patch and click Next until you can Finish. 7) Now, re-build (Project->Clean->Clean all projects). 8) Right-click in the Package Explorer and Run As..->Eclipse Application This should launch a new instance of Eclipse in which you can try the changes. --Cam
I have started an overview page on the JSF wiki to enumerate feature requirements for facelet support. If you are interested in this feature please review and comment here. http://wiki.eclipse.org/Facelet_Support
It would still be nice to have the xhtml/html editor as part of the WST instead of relying on the JFACE and Facelet support. Any thought of splitting out the base code that just handles HTML/XHTML specific items, and then extending the additional functionality needed for JFACE/JSP and Facelet support through extension points? HTML and XHTML designer type functionality can be used by more than servlet development if it is refactored.
(In reply to comment #23) > It would still be nice to have the xhtml/html editor as part of the WST instead > of relying on the JFACE and Facelet support. Any thought of splitting out the > base code that just handles HTML/XHTML specific items, and then extending the > additional functionality needed for JFACE/JSP and Facelet support through > extension points? There is existing support in the SSE editor for XHTML. If you mean that you would like to see the Web Page Editor (visual editor) broken up in this way, I agree it's a good idea but I don't know if the resources exist currently such an undertaking. Best take that up on a separate bug with the WST teams first.
Yeah, I had created bug 199341 for just this request.
(In reply to comment #19) > > much. I am getting attributes on h: and f: (JSF Core/Html) only. The palette > > shows many libraries, but the properties window doesn't seem to get > > information from the same libraries. > Rendering and property view information is dependent on a combination of tag > meta-data and tag information. In the case of h and f, there is default > meta-data present out of the box; not so with other tags. If meta-data is not > present a more generic property page is created based the tag's TLD > information. Unfortunately, the TLD manager doesn't bother to provide this for > files that it doesn't think are JSPs. For almost a year my team has been using a patch similar to yours written against the old TLDCMDocumentManager. By treating facelets XHTML files as JSP content type we get almost all the functionality in the JSF use cases, including EL validation. This is accomplished by applying the attached patch and configuring our workspaces as follows: - Add *.xhtml files to the JSP content type (Window > Preferences > General > Content Types > JSP) - Make the JSP Editor the default editor for *.xhtml files (Window > Preferences > General > Editors > File Associations
Created attachment 83463 [details] JSF XHTML Plugin Patch
(In reply to comment #26) > For almost a year my team has been using a patch similar to yours written > against the old TLDCMDocumentManager. By treating facelets XHTML files as > JSP > content type we get almost all the functionality in the JSF use cases, > including EL validation. This is accomplished by applying the attached patch > and configuring our workspaces as follows: We have done some initial POC's like this one as well. For 3.0, we are working toward a design time view handler that is used to abstract ourselves from the specific View Description Language (VDL) that is used to construct a JSF page. A default implementation will be provided to handle JSP (as is done in the runtime), but it will be pluggable so that alternative view handlers like Facelets will be able to provide support in their preferred document type (i.e. XHTML). We hope to have a POC for people to look at by EclipseCon.
Some additional information on the new design time view handler design: 1) We will for the first time be able to approximate the runtime component tree at design time. This means that we can improve features like validation since we will know what converters and validators are associated with what components and can reduce troublesome false positives on semantic validation when a nested converter may change the type. 2) We will be able to track component ids and so will be able to flag duplicate ids, can assist in managing all the user-defined ids in a page and will also be able to validate the "for" attribute that associates one component with another (i.e. h:outputLabel). 3) We will have much better visibility on parent-child validation. For example, ensuring that form components are inside forms, that a view root is defined etc. and that validators and converters are nested inside components of the correct type to use them. 4) We will be able to better support templating since we will be able to construct component sub-trees based on includes.
This code works fine with jspx editor <!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"> <f:view xmlns:ui="http://java.sun.com/jsf/facelets" xmlns:h="http://java.sun.com/jsf/html" xmlns:f="http://java.sun.com/jsf/core"> <!-- Your code here --> </f:view> </html>
(In reply to comment #30) > This code works fine with jspx editor > > <!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"> > <f:view xmlns:ui="http://java.sun.com/jsf/facelets" > xmlns:h="http://java.sun.com/jsf/html" > xmlns:f="http://java.sun.com/jsf/core"> > > <!-- Your code here --> > > </f:view> > </html> > This is a jspx file.
Removing the 3.0 target. Support for Facelets is being carried out in the JSF Facelets Incubator project, http://www.eclipse.org/webtools/incubator/. This is not part of the WTP 3.0 Ganymede release. We will keep this bug open to track the work done in this area. We will post additional information on the Facelets support in the wiki, http://wiki.eclipse.org/JSF_Facelets_Tools_Project
We will also be having a webinar on June 17 at 1600 GMT (9am PDT, 12pm EDT). See here for more information: http://live.eclipse.org/node/483.
(In reply to comment #32) > Removing the 3.0 target. > > Support for Facelets is being carried out in the JSF Facelets Incubator > project, http://www.eclipse.org/webtools/incubator/. This is not part of the > WTP 3.0 Ganymede release. > > We will keep this bug open to track the work done in this area. We will post > additional information on the Facelets support in the wiki, > http://wiki.eclipse.org/JSF_Facelets_Tools_Project > Should this bug be moved to the Incubator project or if the facelets project has an incubating component should it be moved there?
This is a pity. Facelets will form a conerstone part of JSF 2.0, a spec already out there. Eclipse has already a balklog to catch up with w.r.t. Netbeans (smoother graphical editing of tags) and IntelliJ (better integrated JSF-experience). Aiming for Facelet integration means knowing what the future of JSF is about. I had hope it would already have been part of the Ganymede WTP build. --Wolf (In reply to comment #32) > Removing the 3.0 target. > > Support for Facelets is being carried out in the JSF Facelets Incubator > project, http://www.eclipse.org/webtools/incubator/. This is not part of the > WTP 3.0 Ganymede release. > > We will keep this bug open to track the work done in this area. We will post > additional information on the Facelets support in the wiki, > http://wiki.eclipse.org/JSF_Facelets_Tools_Project >
What is the status of Facelets support now? I see almost no activity since summer of 2008 here: http://wiki.eclipse.org/JSF_Facelets_Tools_Project. I went through Webinar at http://live.eclipse.org/node/483 and tried to use incubator's 0.1 release (from http://www.eclipse.org/webtools/incubator/downloads/) in Eclipse Galileo JavaEE distribution 3.5.1 to no avail. I see Facelets facet and other related elements in wizards, but content assist in XHTML is not working. I understand that JSF 2 support in Eclipse is WIP, but can we get something working for JSF 1.2?
(In reply to comment #36) > What is the status of Facelets support now? I see almost no activity since > summer of 2008 here: http://wiki.eclipse.org/JSF_Facelets_Tools_Project. I went > through Webinar at http://live.eclipse.org/node/483 and tried to use > incubator's 0.1 release (from > http://www.eclipse.org/webtools/incubator/downloads/) in Eclipse Galileo JavaEE > distribution 3.5.1 to no avail. I see Facelets facet and other related elements > in wizards, but content assist in XHTML is not working. I understand that JSF 2 > support in Eclipse is WIP, but can we get something working for JSF 1.2? Tooling support for Facelets will be available in the Helios release of WTP as part of support for JSF 2.0. We are not planning to do any further work in the incubator project.
:-) This all began in 2007 when I posted a request. It's 2010 now and "not ready yet". I switched to IntelliJ mid-2008 because of reasons like this. It's a pitty. Eclipse used to be a nice IDE, now it's plugin-hell (overload & incompatibility issues) and a lack of essential functionality. (Very much like this one. Jsf2 has facelets as it's STANDARD templating mechanism and came out in 2009). To the extend I abandoned my favourite IDE I had used for almost half a decade. Peace, Philippe
This was a very painfull issue indeed for all who did java webdevelopment using JSF - Facelets. Many were looking for good options, some probably switched IDE for this reason! However installing the JBoss tools was the only "good" option available for Eclipse which solved the issue. To any Eclipse-people with influence: please pay attention to the needs of your community. I still rather use Eclipse than InteliJ though ;-) I never have issues to the extent that you are saying. Kind regards, Timothy (In reply to comment #38) > :-) > This all began in 2007 when I posted a request. > It's 2010 now and "not ready yet". > I switched to IntelliJ mid-2008 because of reasons like this. > It's a pitty. Eclipse used to be a nice IDE, now it's plugin-hell (overload & > incompatibility issues) and a lack of essential functionality. > (Very much like this one. Jsf2 has facelets as it's STANDARD templating > mechanism and came out in 2009). > To the extend I abandoned my favourite IDE I had used for almost half a decade. > Peace, > Philippe
(In reply to comment #36) > What is the status of Facelets support now? I see almost no activity since > summer of 2008 here: http://wiki.eclipse.org/JSF_Facelets_Tools_Project. I went > through Webinar at http://live.eclipse.org/node/483 and tried to use > incubator's 0.1 release (from > http://www.eclipse.org/webtools/incubator/downloads/) in Eclipse Galileo JavaEE > distribution 3.5.1 to no avail. I see Facelets facet and other related elements > in wizards, but content assist in XHTML is not working. I understand that JSF 2 > support in Eclipse is WIP, but can we get something working for JSF 1.2? I just verified that content assist in an XHTML file works for JSF 1.2. I verified using the incubator source on a WTP 312 build. I will post a new build to the download site, if you prefer a build. I didn't have to make any changes to the source code.
Response comment 38, comment 39 and comment 40 : The Facelets incubator project was started with the sole purpose of exploring tooling support for Facelets with the main objective of using this experience to add support for Facelets in JSF 2.0 in WTP. We did achieve this objective with the early tooling offered in the incubator project. The delay in the release of the JSF 2.0/Java EE 6 spec forced us to wait for Helios to add this support to WTP. We didn't have the resource to continue working on the incubator project. We understand your frustration at the lack of functional tooling in Eclipse for Facelets after all these years. We hope you will participate in the work we are doing in Helios to support JSF 2.0. -Raghu, Project Lead
Posted build, http://www.eclipse.org/webtools/incubator/downloads/
Raghu, thanks for your quick response, appreciated! I tried 0.2 build in Eclipse 3.5.1 with the same negative result - I see Facelets-related items in wizards, but content assist is not working. I only get HTML and JSP elements there. I tried 3 editors: HTML, JSP and Web Page Editor with the same result. I also tried it on a basic facelet template created via wizard, so it does not look like I'm messing something up on my pages.
Actually, I take my last message back. Success in 3.5.1 now! I just forgot to turn on Facelets facet. Great! Now, is there any way to make content assist in facelets understand JSF managed beans?
(In reply to comment #45) > Actually, I take my last message back. Success in 3.5.1 now! I just forgot to > turn on Facelets facet. Great! > Now, is there any way to make content assist in facelets understand JSF managed > beans? Content Assist does work for managed beans - that was my test.
Yep, I was hasty again, apologies. It does understand JSF managed beans, confirmed. What I have and it does not understand is Spring-managed beans. I used to use JBoss Tools RichFaces (uninstalled now) which does understand them. Spring-managed beans are integrated using this: <el-resolver>org.springframework.web.jsf.el.SpringBeanFacesELResolver</el-resolver>
Support for editing Facelets XHTML files is now part of the WTP Helios release, starting with the M6 milestone build. Thanks for all the great contributions.
But there is no support for JSF 1.2 & xhtml Facelets Editor with Content Assist in Helios anymore. So for JSF 1.2 Projects I must use Galileo with Facelets Tools Plugin and for JSF 2.0 Project I can use Helios. Because Facelets with JSF 1.2 is still used in many projects, why was this support dropped from the feature list?
This bug is about facelets (also in JSF 1.2) not about JSF 2.0. Facelets was used before JSF 2.0 and many projects still are using this combo: facelets and JSF 1.2.
(In reply to comment #50) > This bug is about facelets (also in JSF 1.2) not about JSF 2.0. Facelets was > used before JSF 2.0 and many projects still are using this combo: facelets and > JSF 1.2. There is no plan to support Facelets with JSF 1.2 primarily due to lack of resources. We welcome any contribution to Indigo that will add support for JSF 1.2 and Faclets.We still have Facelets supoprt in the JSF Facelets incubator project.
(In reply to comment #51) > (In reply to comment #50) > > This bug is about facelets (also in JSF 1.2) not about JSF 2.0. Facelets was > > used before JSF 2.0 and many projects still are using this combo: facelets and > > JSF 1.2. > > There is no plan to support Facelets with JSF 1.2 primarily due to lack of > resources. We welcome any contribution to Indigo that will add support for JSF > 1.2 and Faclets.We still have Facelets supoprt in the JSF Facelets incubator > project. The original purpose of this bug has been resolved and hence closing this bug. Tracking the enhancement request in comment 51 in a new bug, 339127. Please add your comments there or create new bugs for new issues.
