No more mandatory component binding in Visual Web

Netbeans Visual Web Designer (NB 6.0 and before) mandates that each JSF component tag in the JSP must have a binding attribute which is bound to a property in the backing page bean via Expression Language binding. This ends up generation of getter and setters for each of the component in the page bean. Even though, this is convenient to set properties directly to the JSF component used in the page, this is very annoying because 95% of the components declared in the page Java source are not used and unnecessarily bloats the backing page bean.

For Netbeans 6.1 release this is going to change. Following changes have been implemented already and available in the Netbeans 6.1 nightly builds.

  • Newly created pages and page fragments will not have any binding attribute.
  • The generated Java source will not contain tons of getter and setters for corresponding properties.
  • The binding attribute in the JSP and corresponding property in the Java source will not be generated when a component is dropped on to the designer.
  • Users will have the option to add component binding using "Add binding attribute" context menu item of the component in the outline or designer.
  • Users will also have the option to remove component the binding using "Remove binding attribute" context menu item.

Here are some test results after the implementation

  • Create a project
  • In the page drop a table and copy and duplicate it to 20 tables
  • Copy the page and duplicate it to 128 pages.


  • Results With binding attribute for each component
    • Extremely slow to copy and create all the pages (more than 20 minutes)
    • Memory in the memory meter reached 512 MB and OME after copying about 95 pages
    • Copy all 128 pages after restarting IDE.
    • Final project size 10.2 MB
    • Restart IDE and Open project and 10 pages (switch to Java) - Memory 120/190 MB
  • Result With out binding  for each component
    • Reasonably faster to copy and create all the 128 pages (about 5-7 minutes)
    • Final Memory in the memory meter (after GC) 165/340 MB
    • Final project size 1.9 MB
    • Restart IDE and Open project and 10 pages (switch to Java) - Memory 75/140 MB

Nice improvement. This will make VWP a lot cleaner and neater...

Posted by Yossarian on January 14, 2008 at 03:29 PM PST #

Good news! I like a clear backing bean.
Also performance was a big usability problem on my machine (Core2 + 4GB mem)
How about an application specific abstract page bean, to manage "getSessionBean1()" and other application/session code in a central place?

Posted by Volker on January 15, 2008 at 01:39 AM PST #

Hi Winston,

That is great news...

May I ask you a question:
I am trying to dynamically change the parent of JSF component..
Let me explain my context:
Components are initially put via Netbeans interface into JSF pages but without any style (that is creating an initial component tree structure)..
The user of my application might (via an heavy client whick takes the role of layout administrator) change the components look (style:position, background color...etc) and also move a component from Panel (or GroupBox) in Tab1 to a panel (or GroupBox) in Tab2 for instance.

What i have achieved till then: JSF component are dynamically positioned and styled when the user click on each tab rendering exactly what he is seeing on heavy client application.... lot of work indeed, but this works perfectly (I need however to have a look on performance issues) when user do not change any parent of the components....In other words, when initial component tree structure is not modified.

BUT, when I try the use case described above (from tab1 to tab2) works when the page is first rendered (component is actually in Tab2 and well positioned) but when I click on Tab1, the component shows up again in Tab1. When I click on Tab2, the component is not there anymore.....?????

The way I am proceeding is as follows:
All initialisation is done in the init function of a managed bean.
public void init() {
// Perform initializations inherited from our superclass
// Perform application initialization that must complete
// \*before\* managed components are initialized
// TODO - add your own initialiation code here
System.out.println("_________ENTERING FICHE BEAN INIT________________");
System.out.println("...........Init components ............");
System.out.println("_________EXITING FICHE BEAN INIT________________");

// <editor-fold defaultstate="collapsed" desc="Managed Component Initialization">
// Initialize automatically managed components
// \*Note\* - this logic should NOT be modified
try {
} catch (Exception e) {
log("FicheBean Initialization Failure", e);
throw e instanceof FacesException ? (FacesException) e: new FacesException(e);

// </editor-fold>
// Perform application initialization that must complete
// \*after\* managed components are initialized
// TODO - add your own initialization code here

and in intComponents, I do:

UIComponent component= ComponentUtil.findComponentInRoot(componentId);
if (component != null){
//Retrieving the parent from heavy client:
String newParentId = componentMap.get(componentId).getParent().toLowerCase();
//Getting the parent in JSF tree structure
String oldParentId =component.getParent().getId();
UIComponent oldParentComponent = component.getParent();
UIComponent newParentComponent = ComponentUtil.findComponentInRoot(newParentId);
if (newParentComponent != null){
System.out.println("newParentComponent getRendersChildren " + newParentComponent.getRendersChildren());
System.out.println("newParentComponent " + newParentComponent.getChildren());

COuld you please help me on this ...Do you have any idea.?

Am I misunderstanding something here ..??

Many thanks in advance

Posted by Nicolas Gaudin on January 17, 2008 at 06:40 PM PST #

Wow what a performance difference! I just tried a daily build and am able to open a Visual Web page very fast, switch to JSP view, scroll and type without delays. Before this change it would take at least 15-20 seconds to load the Visual Designer, then I could switch to JSP view but it would freeze up again for another 10+ seconds. When it would wake up again I could type faster than letters display until it would finish whatever it was doing. Visual Web is becoming usable with this change, and the JSP/backing bean is MUCH cleaner.

I noticed that the 6.1 roadmap talks about bundling Facelets support. I know about the facelets plugin, but will Visual Web also support facelets in 6.1?

If not, then when will we be able to use Visual Web for Facelets and Seam development? I imagine adding support for JSF 2.0 would be much simpler once Facelets and Seam support works well.

Posted by Ryan de Laplante on January 27, 2008 at 12:38 AM PST #

Hi Ryan, thanks for the nice comment and thanks for all the constructive discussions we had (as you nicely articulated in your blog, that lead to these performance improvements.

About your question about facelet support for NB 6.1. The main focus for NB 6.1 seems to be

- Performance improvement.
- Out of the box PhP development support.
- Full fledged Javascript editing support including debugging.

Given these priorities, I'm not sure if facelet could make it in to the product release, but could be an autoupdate module.

Posted by Winston Prakash on January 27, 2008 at 03:20 AM PST #

Hi Nicolas Gaudin, may be we should discuss your interesting scenario off-line over e-mail. Send me an detailed e-mail to wjprakashATnetbeansDOTorg. Thanks

Posted by Winston Prakash on January 27, 2008 at 03:23 AM PST #

I'm happy to hear that my comments had some influence on NetBeans. Regarding Facelets, I see that the issue is in the "TBD" section, which probably means that it might or might not make it in. The summary gives me the impression that the existing Facelets plugin needs to get Sun's seal of approval and bundle it with the IDE instead of having to add it from the update center.

Posted by Ryan de Laplante on January 27, 2008 at 06:12 AM PST #

I used NB 6.1 nightly build to open up an existing project that has component bindings for every tag in the JSP. It feels just as slow as before. Maybe when 6.1 is released I can go through this project and remove all bindings (except the ones I need) to significantly improve my design-time productivity.

Is that what you would expect? An existing project full of bindings will not be faster than it was in 6.1?

Posted by Ryan de Laplante on January 29, 2008 at 03:20 AM PST #

Ryan, Most important performance improvement is on Windows. One of the main culprit was BeanInfo search. To find the BeanInfo all jars in the classpath was searched. As you know, I/O on Windows sucks. When we restrict the BeanInfo search to limited jars, our tests shows as much as 50% improvement in opening a page with several components and first time Table Component drop on Windows Vista. We didn't see that much improvement on Unix machines (Linux/Solaris/Mac).

BTW, you won't see drastic improvement with binding removal if your project is small (tens of pages). Actual performance boost is seen with 100 of pages. We tested with 128 page project.

Anyway, for 6.1 we are not changing the overall architecture of Visual Web, which is planned for later major release (may be NB 7.0).

Posted by Winston Prakash on January 30, 2008 at 02:27 AM PST #

Post a Comment:
  • HTML Syntax: NOT allowed

« December 2016