- This topic has 13 replies, 4 voices, and was last updated 18 years, 2 months ago by
.
-
Posts
-
I’m not sure how to start this topic as I haven’t been able to get a consistent view of the behaviour of the MyEclipse editors with JSP/JSF files.
As far as I can tell, most people code JSP files as invalid XML files. A comment on page 16 of the “Core JavaServer Faces” book, highlights the issue.
In many cases, this doesn’t seem to cause a problem. However, when importing JSPs with subviews, one has to use <f:verbatim> a lot (this might also be needed in the base JSP). This can completely mess up what might otherwise look like a neat bit of markup (because a start tag might be disassociated from its end tag, by verbatim). This is alleviated by using the “<” symbol in place of the left bracket of tags inside a verbatim. However, the code starts to look very ugly when doing this.
Another issue is the use of the <?xml?> directive at the top of the JSP. If this is done, then most documents will fail validation (correctly), because of unclosed tags, as well as the issue mentioned above. The use of JSF tags inside attribute values can also cause errors unless verbatim is used extensively.
When one tries to get a clean XML document, using the “jsp” namespace, symbols and verbatim, the resultant JSP can get a clean validation but can be very difficult to read.
The last issue I want to mention is the use of prompts in the MyEclipse JSP editors. When importing a JSP within another JSP, the outer JSP can define beans that the inner JSP can use (for example, a resource bundle). I’m sure I’ve got the editor to recognise this chain of imports and allow prompting on valid attributes of the bean (resource bundle) in the imported JSP. However, I can’t figure out how I did it and havent’ been able to replicate that feature. Is this possible, or did I imagine it? There is nothing illegal about referencing beans defined in an outer JSP, so the validator shouldn’t flag it as a problem (unresolved reference).
Another aspect of the bean resolution is that, in the outer JSP, it is possible to use a bean reference within a tag attribute (e.g. <a href='<h:outputText value=”#{a.b}”/>’>). However, the validator doesn’t pick up invalid attributes (the “.b” in the example), even though the prompter can show the attributes available.
This is all so untidy. Has anyone used the MyEclipse editors and validators cleanly for more than simple JSF applications? If so, how?
Tony
Tony can you post an example JSP page that you think exhibits all these ‘normal’ practices?
Also as far as include resolution goes, do you mean A defines var ‘blarg’, is included in B, and you want autocomplete in B (supported) or do you mean something else?
@support-rkalla wrote:
Tony can you post an example JSP page that you think exhibits all these ‘normal’ practices?
I’ll see what I can do but I was simply hoping to start a discussion on the topic. Is there a conventional way of developing JSPs that is not really supported by the MyEclipse editors and validators? Would “normal” JSP development see many validation errors and an inability of the editors to exhiit their full functionality? If so, what is the best approach to either development or to further refinement of the tools?
I joined a company a few months ago, which just used raw eclipse for development. I’ve spent a bit of time over the last couple of days seeing if I could make use of the MyEclipse tools for further maintenance and development of existing JSF applications. I found that simply switching the projects to web projects caused a swathe of errors in most of the JSPs. Fixing those errors is rather difficult without making the JSP code very messy, at least that’s what I’ve found so far.
Has no-one else come across these problems, or do people just turn off validation and live with the lack of features? @support-rkalla wrote:
Also as far as include resolution goes, do you mean A defines var ‘blarg’, is included in B, and you want autocomplete in B (supported) or do you mean something else?
I mean A defines ‘blarg’, A imports B and B uses ‘blarg’, with the editor prompting for completions. Resource bundle is the classic example but there are other examples in the code I’ve been looking at. It may be that the JSP editor can’t figure out the import structure and maybe I didn’t get that to work, but I’m almost sure I did. There is certainly nothing wrong with the importing, as the application runs fine, when built. But the validation shows the variable as unresolved, and, of course, you don’t get auto-complete.
A related problem is that when a bean reference is in an attribute of a non-JSF tag (e.g. <tag attr='<h:outputText value=”#{bean.property}”/>’/>), then the validator won’t pick up the fact that the property is unresolved in the bean, even if the editor can see the properties for autocompletion.
Tony
Tony,
Without a sample page it’s hard for me to map what you are saying directly to the 100s of different ways I’ve seen people try and do some of these things. The issue of the imports and the EL validator are simply that these are *very* hard problems to hard consistently. Using scriplets and includes work fine, but defining a resource bundle using a taglib and then trying to use it later in some pages as a bean is a difficult problem, see here for more information:
http://www.myeclipseide.com/PNphpBB2+file-viewtopic-t-13364.htmlAnd no normally people don’t have tons of validation errors when their projects are setup correctly. Some might in the case where they are using non standard constructs that the validator or editor don’t understand but when compiled are actually valid. As a long time JSP developer it’s easy to loose sight of the fact that JSPs are the conglomerated mess of something like 10 valid specifications. Some clearly specified, some not so clearly specified. Any tool that offers full editing support for JSPs has to implement, follow and honor all these ungodly specs and that becomes a real trick.
MyEclipse 5.0 is the first release in a long time that has started adding more advanced support like EL autocomplete and EL validation. These features will improve and get better over time, but if your project is sufficiently complex you may have a hard time getting the tool to do what you want.
That being said I create a small sample JSF 1.2 app using MyEclipse 5.0 and JackRabbit on GlassFish just as a proof of development concept and have no validation errors or problems. Some of the valid things I tried that didn’t work however was using preludes and codas in the web.xml file instead of includes, and also I was unable to define universal JSF resource bundles and have them resolve (and not get marked as errors). But besides those two things, everything else I tried worked out. Then again I wasn’t doing any embeddeing of tags inside tags or anything like that.
rkalla,
I take your point about validators/editors not being able to determine what effect individual tags have (as in that link you provided). In this case, scriptlets ought to be encouraged, because their effect is obvious, although getting away from using Java inside JSPs is a good thing, generally.
I can see that these are tricky problems to solve. There appear to be a few main problems:
- Getting the validators/editors to look back for a chain of includes, so that it has a complete set of information about the currently editted JSP (though there coiuld be several such chains!).
Having the editors/validators understand the effects of tags, in relation to the beans that are made visible to later code. This should be possible with standard JSF/JSP tags (including JSTL and Struts) but impossible with custom tags, without some artificially defined metadata.
Use of JSF constructs (bean references) inside attribute values.
Enabling “cheating” to avoid having to make JSPs valid XML (such as not needing to use symbols like <).
Some of these may be insoluble. It seems that we can, to some degree, base our designs on the tools (to ensure clean validations) but this would be wrong. Having tools validate incorrectly is bad, because validation errrors and warnings can be misleading and can cuase genuine errors to be missed by the developer. Switching off validation may be the only way to make use of the tools, though some editor facilities will be unavailable in some cases.
It would be interesting to see if the eclipse web tools project (which seems to be based on WSAD) manages to solve some of these problems.
Tony
Here’s an example of some JSP, which is valid JSP (though not XML) but which results in errors and warnings when validated by MyEclipse:
<%@ taglib uri="http://java.sun.com/jstl/core" prefix="c"%> <%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %> <%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %> <f:loadBundle basename="eclipse.cp.locale.crmResources" var="msgs"/> <f:verbatim> <div id="activityBar"> <div id="activityBarBG"></div> <div id="crmClock"> <object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=7,0,19,0" width="140" height="140"> <param name="movie" value="images/crmClock.swf" /> <param name="quality" value="high" /> <param name="wmode" value="transparent" /> </object> </div> <div id="linksPane"> <div id="linksPaneContent"> <div id="linksPaneTitle"></f:verbatim><h:outputText value="#{msgs.activitybar_links}"/><f:verbatim></div> <div id="linksPaneLinks"> </f:verbatim> <h:dataTable var="link" value="#{userVO.links}"> <h:column> <h:outputLink value="#{link.appURL}" target="_blank" title="#{link.description}"><h:outputText value="#{link.name}"/></h:outputLink> </h:column> </h:dataTable> <f:verbatim> </div> </div> <div id="linksPaneBG"></div> </div> </div> </f:verbatim>The f:verbatim tag hides the </div> tags from the validator, which thinks there isn’t an end tag for the opening <div>, in some cases (this generates most of the errors/warnings). Other warnings appear for the unresolved userVO and link beans. This is fair enough (since they are only put into the session from code, not from a JSF declaration), but it means that the warnings can’t be removed, they have to be consciously ignored.
Now consider another example:
<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core"%> <%@ taglib prefix="fmt" uri="http://java.sun.com/jsp/jstl/fmt"%> <%@ taglib prefix="h" uri="http://java.sun.com/jsf/html" %> <%@ taglib prefix="f" uri="http://java.sun.com/jsf/core" %> <f:loadBundle basename="eclipse.cp.locale.crmResources" var="msgs"/> <f:loadBundle basename="eclipse.cp.locale.crmSiteResources" var="siteMsgs"/> <f:view locale="#{applicationChooser.selectedLocale}"> <!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"> <head> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" /> <meta http-equiv="Cache-Control" content="no-cache"> <meta http-equiv="Pragmas" content="no-cache"> <title><h:outputText value="#{siteMsgs.windowTitle}"/></title> <link href="css/argentCPltr.css" rel="stylesheet" type="text/css" /> <link href="css/headerltr.css" rel="stylesheet" type="text/css" /> <link href="css/activityBarltr.css" rel="stylesheet" type="text/css" /> <script language="javascript"> <!-- function selectApp(appId){ var theForm = document.forms.appChooser; var theField = document.all['appChooser:appId']; var theButton = document.all['appChooser:submitButton']; theField.value = appId; theButton.click(); } //--> </script> </head> <body dir='<h:outputText value="#{siteMsgs.pageDirection}"/>'> <!-- Header Begins --> <f:subview id="header"> <c:import url="header.jsp"/> </f:subview> <!-- End of Header --> <!-- Activity Bar Begins --> <f:subview id="leftMenuFrame"> <c:import url="activityBar.jsp"/> </f:subview> <!-- End of Activity Bar --> <h:form id="appChooser" target="_blank"> <h:inputHidden id="appId" value="#{applicationChooser.appId}"/> <h:commandButton id="submitButton" type="submit" value="testMe" action="#{applicationChooser.loadApp}" style="visibility:hidden"/> </h:form> </f:view> <c:set var="numAppsPerLine" value="3"/> <c:set var="startLeft" value="0"/> <c:set var="offsetLeft" value="365"/> <c:set var="startTop" value="0"/> <c:set var="offsetTop" value="265"/> <c:set var="top" value="${startTop}"/> <div id="mainContentPane"> <c:forEach var="app" items="${userVO.applications}" varStatus="status"> <c:set var="left" value="${startLeft + status.index % numAppsPerLine * offsetLeft}"/> <div id="appPane" style="position:absolute; top:${top}px; left:${left}px;"> <div class="appPaneTitle"><c:out value="${app.name}"/></div> <div class="appIcon"> <div class="appIconHit"><a href="#" onclick="selectApp(<c:out value="${app.id}"/>)"><img src="images/iconHitArea.gif" /></a></div> <div style="width:150px; height:150px; z-index:30; filter:progid:DXImageTransform.Microsoft.AlphaImageLoader(src='<c:out value="images/${app.iconURL}"/>', sizingMethod='scale');"></div> </div> <div class="appDescription"><c:out value="${app.description}"/></div> <div class="appPaneBG"></div> </div> <c:if test="${status.index % numAppsPerLine == (numAppsPerLine-1)}"> <c:set var="top" value="${top + offsetTop}"/> </c:if> </c:forEach> </div> </body> </html>This suffers from the same problem of unresolved beans (applicationChooser). It also shows errors with the <html> tag (it thinks there is no end tag, possibly because of later “errors”) and the <body> tag (because it thinks the sttribute value is bad). Because there is an error with the opening body tag, the validator seems to think that the first <div> tag is in the wrong place, and that that there is no start tag for the </body> tag.
These are actual files from an existing project that I turned into a web project. I’ll now try eliminating the errors and see what I end up with.
It’s a shame I can’t edit that last post. The second example actually showed the apparent error with the bean applicationChooser only immediately after the project was converted to a web project. When the validation check was run explicitly, that particular error went away. The bean is actually a defined form and shouldn’t have come up as an error. I do still get the other errors.
When I edited the first example, to remove as many of the errors and warnings as possible, I ended up with:
<? xml version="1.0" ?> <%@ taglib uri="http://java.sun.com/jstl/core" prefix="c"%> <%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %> <%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %> <f:loadBundle basename="eclipse.cp.locale.crmResources" var="msgs"/> <f:verbatim> <div id="activityBar"> <div id="activityBarBG"></div> <div id="crmClock"> <object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=7,0,19,0" width="140" height="140"> <param name="movie" value="images/crmClock.swf" /> <param name="quality" value="high" /> <param name="wmode" value="transparent" /> </object> </div> <div id="linksPane"> <div id="linksPaneContent"> <div id="linksPaneTitle"></f:verbatim><h:outputText value="#{msgs.activitybar_links}"/><f:verbatim></div> <div id="linksPaneLinks"> </f:verbatim> <h:dataTable var="link" value="#{userVO.links}"> <h:column> <h:outputLink value="#{link.appURL}" target="_blank" title="#{link.description}"><h:outputText value="#{link.name}"/></h:outputLink> </h:column> </h:dataTable> <f:verbatim> </div> </div> <div id="linksPaneBG"></div> </div> </div> </f:verbatim>Some of the code was wrapped by this forum’s posting behaviour but I had to change most of the “<” and “>” characters between verbatims to symbols, and add an xml declaration. However, I couldn’t get rid of the warnings about unresolved beans.
And I’m not sure that this is a valid XML file, anyway, because of the taglib declarations.
I was able to remove most of the errors and warnings from the second file by moving the </f:view> tag to the end of the file. The only one left was the “Undefined attribute value” for the dir attribute of the <body> tag. However, the validator is not picking up the fact that beans like userVO are unresolved. I have no idea why this is, maybe a bug. Of course, I get no prompt assistance for unresolved beans, but I can’t tell why there is no prompt (although, in this case, I already know why).
So, in the case of the second file, I didn’t have to replace any tag delimiters by symbols, though I did get left with the residual error on the dir attribute of the body tag. To get rid of that, I tried using symbols:
<body dir='<h:outputText value=”#{siteMsgs.pageDirection}”/>’>
but the editor complained that “<body dir='” is an invalid text string! I then tried putting verbatim round the text portions:
<f:verbatim><body dir='</f:verbatim><h:outputText value=”#{siteMsgs.pageDirection}”/><f:verbatim>’></f:verbatim>
but the editor complained that Attribute “body” has no value. However, after closing and re-opening the editor, I found all errors and warnings had gone! There are still unresolved beans but these don’t show up as warnings, as mentioned above.
So it seems to be a bit of a hit-and-miss affair, with the editors and validators, when developing JSF applications. Sometimes warnings show up, sometimes they don’t. For some warnings, there is nothing much I can do about them. Sometimes I have to use symbols (<), sometimes I don’t. Sometimes I have to use an XML declaration (though the document doesn’t necessarily have to be valid XML), sometimes not.
Is this down to how JSF pages should be coded, or buggy editors and validators, or limitations in what can be done with the editors and validators? Or maybe it’s a bit of all of these.
Tony
PS Not all of these changes resulted in a working application, but that’s another story
I’m sorry for getting back to you late, I’ve sent your entire post off to one of the JSP editor developers to have a look at all your examples to see what is going on.
For completeness, here are the files that I ended up with, that had the least validation warnings and that sort of worked (I didn’t get the whole application working but at least the JSP pages seemed to generate some reasonable HTML).
<?xml version="1.0" ?> <jsp:root version="2.0" xmlns="http://www.w3.org/1999/xhtml" xmlns:jsp="http://java.sun.com/JSP/Page" xmlns:f="http://java.sun.com/jsf/core" xmlns:h="http://java.sun.com/jsf/html"> <f:loadBundle basename="eclipse.cp.locale.crmResources" var="msgs"/> <f:verbatim> <div id="activityBar"> <div id="activityBarBG"></div> <div id="crmClock"> <object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=7,0,19,0" width="140" height="140"> <param name="movie" value="images/crmClock.swf" /> <param name="quality" value="high" /> <param name="wmode" value="transparent" /> </object> </div> <div id="linksPane"> <div id="linksPaneContent"> <div id="linksPaneTitle"></f:verbatim><h:outputText value="#{msgs.activitybar_links}"/><f:verbatim></div> <div id="linksPaneLinks"> </f:verbatim> <h:dataTable var="link" value="#{userVO.links}"> <h:column> <h:outputLink value="#{link.appURL}" target="_blank" title="#{link.description}"><h:outputText value="#{link.name}"/></h:outputLink> </h:column> </h:dataTable> <f:verbatim> </div> </div> <div id="linksPaneBG"></div> </div> </div> </f:verbatim> </jsp:root>There are still residual warnings about the unresolved beans, link and userVO, in the above code.
<?xml version="1.0" ?> <jsp:root version="2.0" xmlns:c="http://java.sun.com/jsp/jstl/core" xmlns:jsp="http://java.sun.com/JSP/Page" xmlns:fmt="http://java.sun.com/jsp/jstl/fmt" xmlns:f="http://java.sun.com/jsf/core" xmlns:h="http://java.sun.com/jsf/html"> <jsp:directive.page contentType="text/html; charset=ISO-8859-1"/> <f:view locale="#{applicationChooser.selectedLocale}"> <f:loadBundle basename="eclipse.cp.locale.crmResources" var="msgs" /> <f:loadBundle basename="eclipse.cp.locale.crmSiteResources" var="siteMsgs" /> <f:verbatim> <![CDATA[<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">]]> </f:verbatim> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" /> <meta http-equiv="Cache-Control" content="no-cache" /> <meta http-equiv="Pragmas" content="no-cache" /> <title><h:outputText value="#{siteMsgs.windowTitle}" /> </title> <link href="css/argentCPltr.css" rel="stylesheet" type="text/css" /> <link href="css/headerltr.css" rel="stylesheet" type="text/css" /> <link href="css/activityBarltr.css" rel="stylesheet" type="text/css" /> <f:verbatim> <!-- <script language="javascript"> function selectApp(appId){ var theForm = document.forms.appChooser; var theField = document.all['appChooser:appId']; var theButton = document.all['appChooser:submitButton']; theField.value = appId; theButton.click(); } </script> //--> </f:verbatim> </head> <f:verbatim><body dir='</f:verbatim><h:outputText value="#{siteMsgs.pageDirection}" /><f:verbatim>'></f:verbatim> <!-- Header Begins --> <f:subview id="header"> <c:import url="header.jsp" /> </f:subview> <!-- End of Header --> <!-- Activity Bar Begins --> <f:subview id="leftMenuFrame"> <c:import url="activityBar.jsp" /> </f:subview> <!-- End of Activity Bar --> <h:form id="appChooser" target="_blank"> <h:inputHidden id="appId" value="#{applicationChooser.appId}" /> <h:commandButton id="submitButton" type="submit" value="testMe" action="#{applicationChooser.loadApp}" style="visibility:hidden" /> </h:form> <c:set var="numAppsPerLine" value="3" /> <c:set var="startLeft" value="0" /> <c:set var="offsetLeft" value="365" /> <c:set var="startTop" value="0" /> <c:set var="offsetTop" value="265" /> <c:set var="top" value="${startTop}" /> <f:verbatim><div id="mainContentPane"></f:verbatim> <c:forEach var="app" items="${userVO.applications}" varStatus="status"> <c:set var="left" value="${startLeft + status.index % numAppsPerLine * offsetLeft}" /> <div id="appPane" style="position:absolute; top:${top}px; left:${left}px;"> <div class="appPaneTitle"><c:out value="${app.name}" /></div> <div class="appIcon"> <div class="appIconHit"><a href="#" onclick="selectApp(<c:out value="${app.id}" />)"><img src="images/iconHitArea.gif" /></a></div> <div style="width:150px; height:150px; z-index:30; filter:progid:DXImageTransform.Microsoft.AlphaImageLoader(src='<c:out value="images/${app.iconURL}" />', sizingMethod='scale');"></div> </div> <div class="appDescription"><c:out value="${app.description}" /></div> <div class="appPaneBG"></div> </div> <c:if test="${status.index % numAppsPerLine == (numAppsPerLine-1)}"> <c:set var="top" value="${top + offsetTop}" /> </c:if> </c:forEach></div></body> </html> </f:view> </jsp:root>There is a residual warnings about the text after the </c:forEach> end element tag: “Invalid text string (</div></body>
).” However, if I wrap that text in an f:verbatim element, the JBoss/Tomcat JSP compiler complains that f:verbatim tags should have IDs. I couldn’t get round this, so the above JSP is the best I could get, at the time. There was an odd effect, which is nothing to do with MyEclipse; without the jsp.directive.page tag, the JSP generates a content type of text/xml. I’ve no idea why.An additional note.
I tried to see what it would take to eliminate validation errors from the existing project, without making alterations to the JSPs. I had to turn off validation for HTML Syntax, JSP Semantics (JSF) and JSP Syntax. After doing this, and re-building the project, there were no apparent errors in the JSP files. I say “apparent” because when I opened what is the second JSP above (in it’s original state), the editor showed an error in the right margin and underlined the <html tag, complaining that there was no closing tag. There was no error indicator in the left margin and no error decoration in the package explorer, against the file. I guess there is a bug here somewhere.
Of course, this is not ideal anyway, since I’d like to see genuine errors and potential problems at design time, rather than pick them up at runtime.
Tony
This si kind of cheating, but what if you did something like this:
<f:verbatim><![CDATA[Partial HTML here]]></f:verbatim>
I think Tony has a very good point — the value of the Design view for JSF pages is almost worthless if tags like “msgs” in his example aren’t understood by the MyEclipse validation routines.
Simple example, you want to internationalize text in your app, so your button text is put in a resource file instead of hard coded. Since the validator doesn’t understand the reference, you get a button without any text displayed in the Design panel.
This is pretty basic stuff (IMHO). This really needs to work in order to get the RAD benefits of JSF. Without a GUI that works for stuff like this, JSF will be doomed (at least in Eclipse/MyEclipse — there’s always Sun’s tools I guess).
-cp
