Geertjan's Blog

  • August 22, 2006

Click, Wicket, and the World of Web Frameworks

Geertjan Wielenga
Product Manager
Not long ago I was talking to one of the NetBeans engineering managers and the discussion turned to web frameworks. In contrast to web/application servers, you can't say that an IDE "covers" web frameworks when you provide support for two or three of them. With web/application servers, if an IDE supports GlassFish/SJSAS, JBoss, WebLogic, and Tomcat (with WebSphere somewhere on the horizon), you can truly say that you've covered about 90% of your developer community. (Plus, there's a DIY Kit for you, if you want to provide support for another server, such as Jetty, or Jonas, or Orion, or other servers.) However, this is not the case with web frameworks. Even when you've got support for JSF and Struts (with Facelets coming up in the planning), you've still got 100 (or probably more) viable frameworks that are in actual use in the real world.

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...

Join the discussion

Comments ( 13 )
  • Ahmed Mohombe Tuesday, August 22, 2006

    Thank you very much for the article Geertjan :).

    Of course I'm interested :).

    I started to "work"(well, inspect and proof of concept tests - better said :) ) on the differet aspects that involve such an integration. Unfortunately diving into details brought up more questions for me than answers :), so I'll try to structure and put them together first.

    Regarding the $title, well, that's a different story.

    Click is using Velocity as a template language (it can use JSP too, but Velcity is much simpler for newbies), so the \*.htm pages contain HTML and Velocity code. Including $title in a pages, means that velocity will call "title.toString()" - this is how redering is done - very simple, very efficient, and also very fast. IMHO a plug-in for Click should evenutally depend on a Velocity Language plug-in, and provide to it the "Context", i.e. what variables were used in the according page, so that the completion to be very inteligent.

    But again, this should be the job of another plug-in IMHO, since Velocity (or any other templating languge) deserves a plug-in on it's own to be really complete and does not depend on Click Framework. Of course Velcity is the simplest one, so it sould also be the simplest possible "language plug-in".

    For Eclipse this is not a problem since there already are 3 or 4 Velocity plug-ins (and FreeMarker too), but for NB I haven't found one, so it should be done too (sooner or later :) ).

    This Velocity plug-in doesn't have the highest priority for me now, since Click has a feature called "autolayout", that involves that most html pages will contain only a single line: "$form", or "$table", or "$panel". Only a small percentage of the pages that need other layout rules(so the exceptions) require a little bigger layout.

    Regarding generation, yes, many things will be generated(like the initial click.xml too), but this is not a problem since it will be done by an external API that already does a good job. The Netbeans wizards only need to collect the imput data (fields) an pass to that API to have things generated, like project structure, new pages, CRUD pages, etc.

    Another thing that could increase productivity greatly would be a page workflow diagram, maybe based on http://graph.netbeans.org/, but I havent figured yet how to do it since there's no detailed example for it.

    IMHO such a diagram would be useful not just for Click but for Struts, JSF and all the other web frameworks.

    The commercial Struts plug-in for Eclipse (WSAD) has such a diagram and, and all developers I know, don't want to work with Struts without those diagrams :). (another plug-in that has such diagrmas is Exadel: Docs and Diagram)

    Thanks in advance,

  • Geertjan Wednesday, August 23, 2006
    Your workflow diagram idea is a good one. I've just started looking at the graph library, so maybe we can include that. Secondly, you mention an API to which values from the NetBeans wizards can be passed... which API do you mean? I don't know what you're referring to here. I've googled and a found a few references to Velocity in NetBeans, so maybe we should check to see if there's no module for this (or something in the making somewhere else).

    Basically, I'd be very happy to work with you in providing a Click module for NetBeans. Do you want to create a project on java.net for this? You would be the owner of the project and we would then use the discussion forums to discuss the further development of this module. We would then also be able to keep our code in one place, in CVS (or Subversion). What do you think?

  • Ahmed Mohombe Wednesday, August 23, 2006
    Your workflow diagram idea is a good one. I've
    just started looking at the graph library, so
    maybe we can include that

    That sounds fantastic.

    IMHO such a diagram should be pretty web frameowork idependent, and only a small part of the API should framework specific. This way it could be used for Struts and the others too, so that people using them in Eclipse/WSAD don't miss them if they would like to use NB :).

    ... which API do you mean

    I'm very sorry for not being precise. I responded you on the nbwicketsupport forum too in the same time, so the explanation got spreaded :).

    I was doing a simple generation tool (not ready yet), and I thought that if already does many things, than the NB wizards could just pass the fields to the tool/(the API of that tool), and have the job done. This way, a NB plug-ing for Click would be faster "production ready" :).

    I'm not sure however if this is the best approach for NB. For Eclipse it is, as the Eclipsework plug-in is also using and external tool/API for generation - called Conductor

    Basically, I'd be very happy to work with you in providing a Click module for NetBeans

    Thank you very much. That would be fantastic.

    Do you want to create a project on java.net for this?

    I haven't thought much about this, as I first I wanted to find answers to the small details regarding NB web plug-in devepment, and put everything togeter in a "clean work", without hacks and workarounds :).

    So far there was only one project page, but your approach and a project on dev.java.net is also a very good idea.

    Some I forgot in my previous comment:

    it has a couple of XML configuration files, which I didn't miss while working in Wicket

    It has basically only one XML file, and after a first creation (or generation), one is basically not editing that file (since "automapping=true") - only for the pages that don't respect the naming convention (this convention is however pretty flexible, so 98% of the pages will always respect it). The docs also contain tip of using it.


    I found no NB Velocity plug-in so far :(. Are you aware of someone working on such a plug-in?.

    I studied a little the language plug-in support for NB, but even if Velocity is very simple (the simplest possible), I don't know how to make a plug-in that integrates with an existing language, since it's a template language that can be used with the various languages:
    • When use in \*.html files, to recognize HTML too ,with all the features that the HTML suppot already does, and without the need to reimplement/duplicate everything in a Velocity plug-in
    • When used with \*.java files (mostly for tools that generate java code), to have at least a part of the "editor intelligence" already supported by NB.
    • For other files would be nice too, but the above are the most common, and for \*.html files is used in 95% of the cases.

    Other IDEs like IntelliJ have the concept of Cameleon Tokens for such situations when a language needs to be "mixed" with another - since this is what templates do :)

    A detailed language tutorial like this would also not be bad of course :), but this is another theme.

    Thank in advance,

  • Geertjan Wednesday, August 23, 2006
    Your NBClick page is very cool. I mentioned it in my blog today. For responses on your other excellent points above, please give me a day or two, to think about and look things up a bit.
  • Ahmed Mohombe Wednesday, August 23, 2006
    Your NBClick page is very cool. I mentioned it in my blog today.

    Thank you very much :). Howerver I did nothing special, as the look&feel is the merit of the WIKI (and it's default settings) :).

  • Geertjan Wednesday, August 23, 2006
    Well, it was more a comment on the content and the intention and the direction, and so on, than the look and feel!
  • Geertjan Thursday, August 24, 2006
    Ahmed, I think it would be better if you were to set up a project on java.net -- that way, we'd be able to have this discussion within a discussion forum (to which others can also contribute) instead of here in this blog. It would be very cool to have a 'space' dedicated to discussing and building Click support for NetBeans. But the 'space' needs to be more structured than it is right now, hence my suggestion to use java.net. (Please feel free to send me an e-mail, I don't have your e-mail address unfortunately.)
  • Ahmed Mohombe Friday, August 25, 2006

    Of course it needs a space, and of course we should not misuse comments of a blog for such a thing :).

    As I mentioned earlier, on the simple NBClick page, we can use without problems the Click Frameowork mailing lists (see "Project related pages").

    I for one, use the GMane interface with Thunderbird, since this is the fastest and the most efficient access possible. Almost all open source projects out there use GMane as a gateway. It's much faster than using an email client :).

    If you preffer a dev.java.net solution over the one above than let me know. I'll request a project, but I suppose however that it will take a little more time (some say that it can take a few weeks), as the Click lists are already available, and the WIKI too.

    My email is "amohombe" AT "yahoo" DOT "com"

    BTW, the blog requires my email for posting this, so I thought that the blog owner can see the email addresses of the users that comment :) (otherwise the owner can't respond privately to some comments).

    Thank in advance,

  • Andreas Andreou Saturday, August 26, 2006
    Hi all,
    I'm a Tapestry fanatic :) and also an Eclipse user!
    I'm currently playing a bit with NB 5.5 and looking into modifying https://nbwicketsupport.dev.java.net/

    There are many things there I'd like to modify in order to make it more framework-agnostic... for instance, i'm extracting an EasyWebFrameworkProvider out of WicketFrameworkProvider and making it more generic (by providing some abstract methods like getRelatedLibraryName() or getFileInitializationAction(WebModule webModule), e.t.c).

    So, i'm thinking of a thin layer on top of what netbeans provides - a layer from which all such frameworks (and there are too many!) can benefit.

    How about nbweb4all as a name?

    I'm also aware of Alex Kotchnev's efforts, but I couldn't resist giving this (and NB) a try.
  • Ahmed Mohombe Sunday, August 27, 2006

    So, i'm thinking of a thin layer on top of what netbeans provides - a layer from which all such frameworks (and there are too many!) can benefit.
    How about nbweb4all as a name?


    IMHO that's it's not the best way to invest energy.

    Most frameworks these days suffer from too much abstraction and lots of things that no one really needs and only makes the learning process very long and hard.

    IMHO the elements that are really common to most of the web frameworks, should be really go directly into the Netbeans web SPI and API, without extra abstraction layers. IMHO these features should be added with concrete usage from the already existing modules that depend on the web SPI/API. This is the most efficient possible solution.

    I like the NBWicketSupport example, because it is concrete. People need and learn by examples, not from abstractions.

    This is also true for web frameworks, and the reason I joined Click Framework: it's very concrete, fantastic documentation ,and is very easy to learn (one is really productive after 1 or 2 days - even to learn pure JSPs take more time).

    just my 2 cents,

  • Andreas Andreou Sunday, August 27, 2006
    i guess you didn't really get my point... which is that I just started playing with Netbeans plugins, and while looking at the nbwicketsupport code and how I could use it for a Tapestry plugin (doing stuff similar to what Alex describes), I find myself constantly copy-pasting their code and simply changing a few values here and there...

    Figuring that others my also opt for similar approaches and practices, I simply proposed that thin-layer... and having that layer evolve in an internal NB API or module would be nice, but there's no reason why not to make the start ourselves :)

    BTW, there's no need for anyone trying to demonstrate how cool his framework is... I'm not here to try to change your preferences - I simply feel we can all work together towards the goals we share.
    Perhaps we should continue this somewhere else?
  • Ahmed Mohombe Monday, August 28, 2006

    I'm sorry for not expressing myself very good.

    I got your point, however my point was that it would be better if that "Layer" would be a "Netbeans Patch" instead of another project (and "layer"). Petr (the author of the nbwickt plug-in said:

    At first I would like mentioned that the Framework API is
    very small and was mainly created for supporting JSF and
    Struts in NetBeans.

    See this on the nbwicket forum.

    So IMHO that existing NB Web support "Layer" should be improved (since it's nor general nor powerfull, nor good enough yet), and not to build another layer one on top of it (the "base" must be good and solid to build things on it, right?). (My "dissertation" about abstraction was related to the API, as if the contribution you mention would go directly in NB, it would be simpler to use for everybody).

    but there's no reason why not to make the start ourselves

    To start yes, but IMHO there are many reasons why we should do it directly into NB, and not "evolve" it from a separate project:

    1. Less work

    2. NB is open source, so people are allowed to contribute directly there

    3. It would be "official", so every framework developer would get it.

    3. It would get good review from the NB team.
    4. many many more other reasons to do it directly into NB :).

    there's no need for anyone trying to demonstrate how cool his framework is

    Sorry if I gave you that impression. Right now I'm working in my dayjob on a Tapestry based project :), and my point with Click Framework was just to ilustrate the need of simplicity (at least from my point of view - or maybe I'm just too stupid for complicated things :) )

    If we need a "repository" or "collaboration place" for the things till the patch would be accepted, IMHO the best place for this would be still the NBWicket plug-in itself, sice the author is NB Web Team member and the right person to "apply" the patch(es).


  • Ahmed Mohombe Monday, August 28, 2006
    Hi Andreas,

    I just saw that Geertjan already created a forum for NB web framework general discussios

Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.