Back in October 2006, I remember eagerly awaiting the final release of the NetBeans 5.5 IDE as I do today for 6.0. Only days before the final release there was an announcement about a new pack for NetBeans – Visual Web Pack. Sun Java Studio Creator was being turned into an addon pack which would enable developers to create JSF web applications visually while taking advantage of the features of NetBeans 5.5. I downloaded the technical preview and have been using it ever since.

Before using VWP I was using Struts. I had read a book called Core JSF but didn't have much hands on experience with it. VWP eased me into JSF without throwing me into the deep end. Some of the features that I really liked were:

• The view controller or page controller events on every page: init(), preprocess(), prerender(), destroy()
• The ability to drag/drop a component onto a page and have it generate the appropriate JSF markup (which can be large) in my JSP.
• The ability to tweak the properties of a component using the properties Window.
• The ability to right click a component, click “Bind to data”, and see a dialog to help me choose a managed bean, and the getter method to bind.
• The ability to right click a component and have the IDE generate an empty event listener or validator method, and attach it to the component.
• The ability to preview my screens in the IDE without having to deploy.
• The ability to visualize my page flows.

There were some things that I did not like about it too. Some of these things made me question whether or not I wanted to continue using VWP or work in JSF without a visual designer. I learned to live with these issues because of the pressures of work and the need to make progress. Lately I've been talking with other developers who have been using or evaluating VWP and found that they have had the same feelings. Some have even chosen to stay away and either use a different IDE, or work without a visual editor.

Sun has been working very hard on the NetBeans IDE and have been doing a phenomenal job, especially in 6.0. I thought that they might appreciate some constructive feedback from someone who uses Visual Web Pack frequently. I sent a rather long email to Winston Prakash from Sun, who is one of the architects of Visual Web Pack. He was pleased to read my feedback and had a lot of interesting things to say in response.

Before I go into detail about my suggestions for future Visual Web Pack ehancements, I must say that these are only early discussions. No solid direction or schedules were devised.

I don't like how every tag is bound to a backing bean component

Almost every single tag in your JSPs are bound to a backing bean component. Even the html, head, title, and body tags use special VWP specific tags (webuijsf:*) and are bound to the page bean. JSF does not require every tag to be bound to a backing bean. This clutters my JSPs with a lot of extra characters. There is a very large chunk of code in my page bean that is collapsed (code folding in the IDE) with getters and setters such as getHtml1, getHead1, getBody1, getForm1, getStaticText1, etc. I thought these bindings were necessary to make the Visual Designer possible.

It is because of the way VWP Designtime System works. Designer simply displays the HTML rendered from the components. If you noticed , in the project there is no extra metadata. The designtime system keeps all the components as Java Beans, including HTML tags (HTML tags has pseudo Java Bean classes, that is how it shows the HTML attributes as properties in the property sheet). For JSF tags, actual JSF components are resurrected as Java Beans from the Page1.java when the project is opened. After closing the project, if you manually remove the corresponding getter and setter and the binding in the JSP, and open the project again, then VWP can not resurrect the Java Beans corresponding to the component. The component renderer will not be called and nothing will be displayed in the designer.

We are investigating different ways for the designtime system to work for the future release, so that there will not be a need to add the getter/setter for the component for every tag.

We are thinking of ways to find the corresponding component from the tag itself (via tld and faces-config.xml), rather than relying on the getter/setter from Page1.java

I asked if that would still work in JSF 2.0 when JSP and faces-config.xml will be optional.

I'm in the JSF-314 expert alias and working closely with Ed-burs (JSF spec lead). You are right. JSF 2.0 may not use JSP and there are plans to use annotations in place of faces-config.xml. We will keep this in mind in our future design.

I suggested that there should be no bindings whatsoever for any tag or component, unless the developer specifically wants a binding so that (s)he can access the component from code. Maybe the developer could right click the tag or component in the outline view, or the visual designer, and click a “Create binding” context menu item.

Actually we were brainstorming about creating the binding only if user right click on the component in the outline and select create binding (in our TODO list)

Winston asked me to create a P1 enhancement ticket for this suggestion in the NetBeans IssueZilla. I created ticket #113015. He clarified that “future release” would certainly not be the 6.0 or 6.1 release (if there even is a 6.1 release).

Allow me to delete the Faces Lifecycle Listener callback methods in my page beans

Every page bean has callback methods for the JSF lifecycle events: init(), preprocess(), prerender(), destroy(). I think this is one of JSF and VWP's great features. Plain JSF does not provide these specific callbacks in your page beans. VWP transparently plugs in a listener and does the callbacks itself. I use the init() method a lot to load values into some components, and initialize the page.

I usually do not need every one of the callback methods, and there are many pages that don't use any of them. Since VWP page beans extend an AbstractPageBean class, I figured that I should be able to delete these methods because they are probably just overrides of empty methods in the super class. VWP puts these methods back into my class whenever I re-open the file. I don't like this.

These methods are nothing but call back methods hooked to the Faces Lifecycle Listeners. Originally, we did not impose the automatic insertion. But we had to do that because of several bugs filed. Some of the methods, such as init() and destroy() are used to initialize and clean up some of the artifacts such as dataprovider. If user delete these methods, then initialization and clean up won't occur during Faces Lifecycle and user did not have a clue on what is going on

The solution may be to have VWP option "Allow deletion of Application Model methods" (with proper warning about artifact misbehave etc). Advanced users, who are sure about what they are doing can delete these methods after check and select the option.

I can understand and like Winston's idea. I suggested that the default comments created for the callback methods be updated so that novice users find out about this setting. He agreed, and asked me to create a P1 enhancement ticket for this suggestion. I created ticket #113018.

Give us a split screen editor

I would like to see split screen where the visual designer is at the top, and the JSP code is at the bottom. I've seen this in Eclipse based visual editors, Dreamweaver, and in other IDEs. I was surprised to hear that VWP already supports a split screen mode, even in NetBeans 5.5! Simply right click your editor tab, and select “Clone Document”. This creates a cloned tab. Drag the second tab down towards the bottom of the screen. You will see red guide lines showing where it will be if you drop. Drop near the bottom of the screen. Now select the JSP view in the bottom tab and you have a split screen editor!

The only problem I've found with it is that as I type changes in the JSP window, the visual editor does not show the changes until I press the refresh button. I have filed ticket #11345.

Make the visual designer more generic

If they could do that, along with my first suggestion of removing the dependancy on backing beans, then the visual designer could be used to visually preview and edit any HTML or JSP file in any project. It could also be used with other web frameworks.

Yes, we are looking in to this option for future release, with support for facelet and other frameworks etc.

There is a Netbeans plugin that support seam development (But not visual). It would be an interesting idea to support visual Seam Development in VWP

We have great ideas for the future release of VWP with greater support for other frameworks. We spent two cycles (5.5 & 6.0) mainly to tightly integrate Creator in to Netbeans as VWP. That task is done. Next level is for lots of enhancements like you mentioned above.

That is very exciting news. I checked the Facelets plugin website. It looked like there was only support for NetBeans 5.5, not 6.0. I was unable to post a message in the forums (even when loged into java.net) so I joined the mailing list and sent a message. Peter Pisl (the Sun engineer who is developing this plugin) responded:

I work on this. I just need to finish some editor issues and it can be released a version for NetBeans 6.0.

More excellent news. I've been playing with NetBeans 6.0 daily builds a lot lately and really love the new features. It is still a bit buggy, but very usable. I've been creating tickets for bugs as I find them.

Please post your comments and suggestions for Visual Web Pack here. I'd really like to read them. For more information on Sun's plans for Visual Web Pack, check out the wiki.