VW binding removal

Removing the need for component binding for each JSF tag in Visual Web

Modification History:

  • Oct 16, 2007 - Winston Prakash



This proposal outlines the necessary modifications in Visual Web DesignTime to eliminate the need for component binding in each of the JSF tag in the JSP page. If there are several components in the JSP page this bloats up the Java page and might cause performance and scalability issue. A bug (#118819) has been filed which states that the Java Source has grown more than 1 MB and Java Editor could not handle it correctly.

Why binding was needed?

Visual Web DesignTime (NB 6.0 and before) mandates that each JSF component tag in the JSP must have a binding property. This due to two reasons.

  • Olden days when Creator was meant for the mythical "Corporate User", the architecture designers has the notion that everything (including visual components & non visual components such as data provider or component modles) is modeled as a JavaBean and added to the backing Java source (Page Bean). The user would typically work with that bean, setting it's properties etc. In order to bind that Java Bean to the JSF tag, binding property is used.
  • Easier component tree creation. Java is the king. Java Source is modeled first. A flat list of Java Beans corresponding to each of the properties in the backing bean is created first. In case of JSF this Java Bean is the actual JSF Component. Then this flat list of Java Beans is mutated in to a component tree based on the JSF tag hierarchy in the JSP. The "binding" property of the JSF tag is used for finding the corresponding Java Bean and place it in the correct hierarchy.

If a Java Bean is corresponding to a JSF tag, then it is called Markup Bean. Markup Bean can have properties which are marked as "attribute" (specified in the BeanInfo and defined in the Tag Library). If a property is an Attribute Property then it is persisted in the JSP, else get persisted in the Java.

Simple solution for now to remove the binding

  • Do exactly same as above. It is needed because if any component exists in the Java source and its binding is specified in the JSF tag (say manually placed binding), then it should be resurrected correctly. Also it helps to model the non visual components (dataprovider) also and place it in the Design Context to be used by the data binding dialogs.
  • When the JSP is modeled and the flat Bean list is mutated in to a tree by traversing the JSP tag hierarchy, if there is no corresponding Markup Bean in the flat list, then delegate a task to JSF Support DesignTime Faces Container to find the corresponding JSF component and insert it in to the hierarchy as a Mark up bean. It is done as follows
  • Get the prefix and the tag name from DOM Element (Ex: <webuijsf:table> - Prefix = webuijsf, TagName = table).
  • Find the TagLib URI corresponding to the prefix from the XML NameSpace declaration (Ex. xmlns:webuijsf="http://www.sun.com/webui/webuijsf")
  • Now ask DesignTime Faces Container to find the JSF component corresponding to the TagName and TagLib URI.
  • The Container first finds the Tag definition Library corresponding to the TagLib URI as a resource from the jars in the ClassLoader (Ex. META-INF/webui_jsf.tld for JSF components).
  • Parsed the TLD library and find the Tag definition corresponding to the TagName (the parsed results are cached for future use)
  • From the tag definition find the Tag Handler class
  • Invoke the method "getComponentType" of the Tag Handler Class and get the Component Type for that Tag
  • Find the faces config file that defines that Component Type as Class Loader Resource (META-INF/faces-config.xml). (More than one resource can be returned. Rather than parsing all the faces-config file, I'm restricting it to the matching URL pattern of the TLD file).
  • From the Component Type definition find the corresponding class and return the result. Again the parsed results are cached for future use.

When the component is dropped on to the desiger, a Markup Bean is created from the Component Class defined in the Palette item and inserted in to the component tree hierarchy. The parent bean is determined based on where it was dropped in the designer. While doing this, DesignTime system

  • Injects a property (getter/setter) corresponding to the JSF component in to the backing bean
  • Adds a binding attribute to the JSF tag inserted in to the JSP tag hierarchy.

With the elimination of binding requirement above two are not needed and removed from the DesignTime tasks. So in the JSP source, by default no binding attribute is added and in the Java Source no property corresponding to that component binding is added. This significantly reduces the number of lines in the Java Source.

Prototype and long term goals

Oct 16, 2007 - I have a prototype implementation of the above concept and it works with some small glitches which I need iron out. I'll post the NBMs corresponding to my changes in this page soon.

The long term goal would be to use the combination of Tag Handler and JSF Component to avoid the need to specify several of the informations in the BeanInfo. Currently the Java Source is modeled first and then JSP hierarchy is used to mutate the flat list. This requires an algorithm with O(N2) performance to find the Markup Bean corresponding to the JSF tag. In future we should model the JSP first and create the Mark Bean hierarchy without the need for searching Markup bean in the flat list. If a JSF tag has some attribute that has binding and if the Java Source corresponding to that binding exists then we should model that Java Source. This would eliminate the need for Designtime System to guess the Java Source that need to be modeled first to create the flat list.

Related Links

Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo