So, my theory is, also because each web framework brings with it a set of concepts and structures that are foreign to other web frameworks (i.e., each reinvents the wheel or resets the wheel or makes someone else's wheel rounder or does something or other with someone else's wheel, like combining one wheel with another and making a... square), that providing support for web frameworks to an IDE must at some point end up being community driven. In other words, not driven by the IDE's community, but by the web framework's community. The nbwicketsupport module has had a few contributions from one or two people, several months ago, but currently seems to be more interesting to developers who would like to provide support for their own framework, rather than extending the Wicket module. That's great and also definitely part of the reason why the Wicket module was developed in the first place.
Ahmed Mohombe from the Click framework left some comments in this blog over the last few days (Ahmed, I left some responses to your comment from a few days back). Click seems a pretty interesting framework. For one thing, I like how the assumption is that the HTML file (the rendering side of a Click web page) is stored in the web folder, rather than (as in Wicket) in a Java package. You can also name the Click HTML page whatever you want (also unlike Wicket where the HTML and Java sides must have the same name). Other than that, it has a couple of XML configuration files, which I didn't miss while working in Wicket. However, the cool thing, from a NetBeans development side, is that having an XML file in your framework means that if you want to provide support for it in an IDE, you have a great opportunity to do something useful... provide support for the XML files. Here, for example, is a drag-and-drop interface for the click.xml file:
This drag and drop interface is based on the JBoss Deployment Descriptor sample that you can find in my update center. By the way, creating this drag and drop interface is not much fun. There is so much boiler plate code. This particular API is crying for a wizard to generate everything for you. The only thing you really want to code are the items, not the palette itself. If I have time, I'll create that wizard myself, because I know exactly what it should provide (at least 7 different files can be generated from a wizard, in this case).
There's obviously lots of things one could do to support Click (or any other framework). As Alex Kotchnev has done here, you can simply pull the WebFrameworkProvider class from the Wicket module and adapt it to your own web framework, to register it in the IDE's Frameworks panel. That will allow you to define what a Click application structure should consist of (for example, instead of creating the click.xml file by hand, it would be generated by the wizard that creates the project).
After the WebFrameworkProvider class has been used to generate a project structure, you can look at ways of making the editing/development process easier. For example, in Click you have variables such as $title. Maybe it would be nice to create a hyperlink from that variable which, when clicked, would open... something. What should it open? I don't know because I am not a Click developer. So... calling all Click developers! Let's put together a plan and create some support for your web framework. Ahmed Mohombe, for example, want to pitch in?
And where are the Wicket developers who use NetBeans? There must be a few of you interested in expanding the IDE to support your favorite framework...