This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
| Summary: |
Designer does not render contents of verbatim tag when inside of anything other than form. |
| Product: |
obsolete
|
Reporter: |
bugbridge <bugbridge> |
| Component: |
visualweb | Assignee: |
Winston Prakash <wjprakash> |
| Status: |
NEW
---
|
|
|
| Severity: |
blocker
|
CC: |
gjmurphy, lfitzgerald
|
| Priority: |
P2
|
|
|
| Version: |
5.x | |
|
| Hardware: |
PC | |
|
| OS: |
All | |
|
|
Issue Type:
|
ENHANCEMENT
|
Exception Reporter:
|
|
|---|
Original status: 5-Cause Known; Suggested Status: NEW Original Target Release: mako_dev; Suggested Target Milestone : Dev These items should be added to the Status Whiteboard: WAV Original submitter: gjmurphy Description: In a new project, drop a group panel component on the designer. Now drop two verbatim tags, one inside of the panel, one anywhere else on the page. Switch to JSP view, add the following content to both verbatim tags: <b>Some text in bold.</b> Notice that text inside of panel does not render. Deploy, and compare the difference. For simple use cases like this, there is a work-around, which is to put the markup into the "text" attribute of the static text component, and turn off its "escape" property. However, the complaints that have surfaced on the forum involve much larger chunks of code. ALso, it is much easier to author markup in the JSP editor. Evaluation: Yes, the issue is there, investigating where is the problem. Evaluation (Entry 2): It seems that the renderer doesn't provide the needed data. Run with switch -J-Dcom.sun.rave.css2.FacesSupport=0 and you'll see there is nothing from the renderer which designer could show. For form containing group panel with two verbatims, one in the group panel and one in the form, the renderer returned something like the below, you can see only one verbatim is returned from the renderer, but nothing for the group panel, so there is nothing designer could show. Passing back to components. [com.sun.rave.css2.FacesSupport #4] Rendered bean=[FacesDesignBean instanceName:page1 xxx@xxxx <?xml version="1.0" encoding="UTF-8"?> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta content="no-cache" http-equiv="Pragma"/> <meta content="no-cache" http-equiv="Cache-Control"/> <meta content="no-store" http-equiv="Cache-Control"/> <meta content="max-age=0" http-equiv="Cache-Control"/> <meta content="1" http-equiv="Expires"/> <title/> <script src="jar:file:/spc/cvs/working/rave/leopard/ravebuild/rave/rave2.0/modules/ext/defaulttheme.jar!/com/sun/rave/web/ui/defaulttheme/javascript/formElements.js" type="text/javascript"></script> <link href="jar:file:/spc/cvs/working/rave/leopard/ravebuild/rave/rave2.0/modules/ext/defaulttheme.jar!/com/sun/rave/web/ui/defaulttheme/css/css_master.css" rel="stylesheet" type="text/css"/> <script type="text/javascript"> var sjwuic_ScrollCookie = new sjwuic_ScrollCookie('/rave', '/rave/rave'); </script> <link href="/resources/stylesheet.css" id="link1" rel="stylesheet" type="text/css"/> </head> <body id="body1" style="-rave-layout: grid"> <form action="/rave/rave" class="form" enctype="application/x-www-form-urlencoded" id="form1" method="post"> <f:verbatim> <b>asfafasdfasdfafasdf</b> </f:verbatim> <span class="rave-uninitialized-text rave-design-border" id="groupPanel1" style="height: 310px; left: 144px; top: 96px; position: absolute; width: 392px; ">Group Panel</span> <input id="form1_hidden" name="form1_hidden" type="hidden" value="form1_hidden"/> </form> </body> </html> Evaluation (Entry 3): This has nothing to do with renderers. Verbatim has no renderer class, only a tag class. The problem is that designer works fundamentally differently than a JSP run-time engine. It does not invoke the tag classes, and so it has notion of the special tag methods that allow a tag's content to be output at different moments in the parsing cycle. I'm not sure that we can even fix this bug, but it would be a good idea nonetheless if the designer team could familiarize itself with the tag class methods, to see if we find a way. Evaluation (Entry 4): Designer is not the one who simulates JSP runtime engine, or is supposed to know anything about JSP/JSF. It doesn't invoke renderes etc. It only renders whatever html(like) output is passed to it. The designtime structure which is created based on the sources in created in insync or jsfsupport. Those parts are responsible for creating the model structure. Passing to insync first. Also now the flat for seeing the renderer output is changed to: -J-Dcom.sun.rave.insync.faces.FacesPageUnit=0 Evaluation (Entry 5): Insync only builds the model using DesignBeans which wraps Components. Apparently the verbatim tag does not have a corresponding component. That causes the problem. As per discussions with Gregory, this could be handled at disgntime similar to the way reqular html tags are handled using the xhtml components. Evaluation (Entry 6): I don't think adding special design-time component and renderer for verbatim is a complete solution. As of JSF 1.2, JSF container components may contain other XHTML markup. The markup need not be inside of a verbatim tag to be rendered correctly. For example, consider this simple example: <h:panelGrid binding="#{Page1.gridPanel1}" id="gridPanel1"> <webuijsf:button binding="#{Page1.button1}" id="button1" text="Button"/> <f:verbatim> <b>--- inserted in verbatim ---</b> </f:verbatim> <b>--- inserted outside of verbatim ---</b> <webuijsf:button binding="#{Page1.button2}" id="button2" text="Button"/> </h:panelGrid> At design-time, one sees only two buttons. At run-time, one sees: Button inserted in verbatim inserted outside of verbatim Button The best way to deal with this is probably to imitate the logic used in the Faces tag classes. The class tag base class, upon encountering literal markup inside of a container component's tag, creates new children components for the markup, with transient set to true. This allows everything, components and non-component markup, to be rendered correctly, in document order, by the container component. We could do the same thing in Creator if we added beginRender() and endRender() methods to MarkupDesignInfo. A check could be made for markup design bean children that do not correspond to components, and temporary components could be created for each. A bug has been filed against JSR 273 asking for the addition of such methods, see https://jbdt-spec-public.dev.java.net/issues/show_bug.cgi?id=19 Suggested Fix: JSF 1.2 runtime solves this problem by creating temporary components for element children of component elements for which rendersChildren == true. For next release, we should investigate a different design-time component hierarchy, where component instances have all the same children as their DesignBeans, including "component" instances for all MarkupDesignBeans.