Geertjan's Blog

  • February 28, 2007

About Those Blue Blocks...

Geertjan Wielenga
Product Manager
There's a school of thought that sporadically raises its head to complain about the NetBeans "blue blocks", i.e., the guarded blocks that contain the generated code provided by the "Matisse" GUI Builder. Especially those that want maximum control over their code tend to get a bit worried, justifiably, that they can't fiddle and tweak with what is, after all, their very own code.

Not everyone seems to know that it has always been possible to do so, however. You can select any Swing component in the GUI Builder, open the Properties window, and then open the Code tab. In there, you'll find 'properties' like "Pre-Init Code" and "Post-Init Code". When you click the elipsis, you get a full-blown albeit small Java editor (e.g., including code completion and syntax highlighting). There you can add initialization code, creation code, and so on. Admittedly, this is still not ideal. It's a bit cumbersome and odd to add bits of code like that. And there are many places in the code that are not covered by these 'properties'. Well, the first bit of good news is that in 6.0, there are about twice as many of these 'properties'. For example , "Pre-Declaration" and "Post-Listeners". However, as in 5.5 and before, you need to do a bit of trial-and-error to see where the code you specify as one of these properties ends up.

So... how cool would it be if you could right-click a Swing component and then choose "Customize Code". You'd then get all the code related to the Swing component and then you'd be able to edit it all and click OK in the knowledge that it would be safely integrated into the blue block? Well...

The above dialog appears when you right-click on a Swing component in the GUI Builder (in NetBeans IDE 6.0 Milestone 6, and probably before that milestone, and probably definitely after that milestone) and choose "Customize Code". There's all sorts of code and settings that you can specify for the entire Swing component, all in one place.

This is unlikely to satisfy the hard-core blue block haters. However, it is clear that this new dialog is a response to the oft-heard unhappiness around this aspect of the NetBeans GUI Builder. At the very least you've got to admit that this is a pretty strong compromise. You're still not able to tinker with the entire piece of generated code. However, you are able to tinker with all the code relevant to specific Swing components. It's worth your while to play with this for a bit and see how it works for you. You'll be surprised how far you can get with this, in terms of controlling the code that the IDE generates for you.

And, finally, it makes sense that there are some limits to this. If you were going to completely wreck your source code, how would the GUI Builder be able to deal with that? At the very least, you can always be sure that the source and the design view are in sync, because the generated code is guarded. But, as you can see, you'll be given a lot more room to manoeuvre within these constraints than before.

Join the discussion

Comments ( 9 )
  • Glenn Wednesday, February 28, 2007
    First, let me say that I think Matiesse is an amazing tool.

    The guarded code blocks have always bothered me from a clean separation perspective, however:

    Why isn't ALL the layout code (i.e. the generated code) in a separate class? As in MVC...

    Leaving it in the same class is simply tempting people to tweak it, and sending a mixed message on the development metaphor. Matiesse, on the one hand, is a GUI builder that "just takes care of it", yet there are these code artifacts lying around....

    Why can't we start thinking of Matiesse as a compiler of sorts (assuming 100% of Swing functionality is available, in some form, of course; the code editing in the properties tactic you describe should suffice, but all of the properties need to be editable, either directly via code or through a properties sheet).

    I would prefer that the code be automatically compiled, furthermore, with the .java file not produced by default (but be available as an option for the curious).

  • Anders Wednesday, February 28, 2007
    Hmm.. This looks great.
    Really, it hasent bothered me for a while that one cannot edit the guarded block - after i got used to enter my code into the block if needet by use of the code block of a swing component.

    I however has one \*big\* problem about the guarded block, and that is that it seems that no refactorings touch the guarded block, and changes to the declared name of a component is not treated as a refactoring outside of the guardet block.

    In my case i has a lot of gui files (50+) which should be in one package - but they are not. I however cannot move (by refactoring) the classes without all actionperformed (and like) methods inside the guarded blocks is faulty.
    This i can fix either by closing nb. and editing the .form files or by renaming the event.

    This makes refactoring in any gui class a major pain.
    Anyone knows whether is to be fixed in NB 6?
  • Gustavo Wednesday, February 28, 2007
    IMO, people shouldn't code in Matisse-generated \*files\*, not only guarded blocks. Build a separate Controller, delegate actions there, and let Matisse handle the view. Java is perfectly OK as a language to describe the view, only if you take that file as a resource, under total control of the builder. If you start to mess with logic in the view class, then, as Glenn said, MVC is broken.
    Matisse is great... just code elsewhere.
  • evanx Wednesday, February 28, 2007
    looks great! i'm pleased one can change the variable declaration eg. to protected. Then one can write a separate controller class for the form in the same package, and access the components.
  • Ahmed Mohombe Thursday, March 1, 2007

    It would be very cool if you could write a set of articles (blog posts) the same way you did about the Graph Library (btw. they're a great help), but this time about project Schliemann:


    IMHO this looks like one of the greatest improvements in NetBeans so far, because in every IDE, adding good support for a new language(not just syntax highilight) is a very difficult task.

    With that module, it seems (at least from the promisses) that it would be very easy to support new languages.

    Unfortunately the documentation is amost inexisting so your articles could be used even there, and would help the project to get a bigger feedback.

    I know that the mentioned module is still experimental, but since you have a closer contact to the developers, you could write those docs, whereas the users (we) can't \*(but would like to use it).

    I can imagine that support for Python would increase the acceptance of NB since Python is used in many science/reasearch areas, and even for web development:



    There are of course, many languages that could be added(and the community will do that), but the community needs now some good docs and very good examples.

    Thanks in advance,


    P.S. Also since that a module is highly innovative, IMHO those tutorials should be posted at least on www.dzone.com if not on Javalobby and Theserverside.
  • Donal Thursday, March 1, 2007
    I haven't used NetBeans for years, but last time I was using it I used to workaround the problem by adding block comments before and after the blue boxed like this
  • Christo Thursday, March 1, 2007
    I also find the lack of refactorings a very annoying problem. My biggest annoyance is with the "Pre-Init Code", "Post-Init Code", etc. blocks that do not have some way of accessing the component field name in a generic way. A lot of times I just want to add the same additioanl initialization code like setting a new editor on a jspinner. I do not want to extend jspinner just to add some new default editor. The editor needs a reference to the spinner i'm attaching to. The constructor for a default editor is "public JSpinner.DefaultEditor(JSpinner spinner)". In another case I'd like to register some components to my own databinding scheme. To do this i would like to write some code, ex: "register( $variable );" where $variable will then be substituted correctly with the variable name of the gui component. This would be a really nice help. This customization gui does not impress me as much if it does not support this kind of variable substitution.
  • Ramon Friday, March 2, 2007
    I find the idea of Ahmed a good thing. It would be great if you could help us with that (Schliemann) Geertjan
  • Geertjan Friday, March 2, 2007
    Hi all, thanks for the many comments. Firstly, yes, I will write about Schliemann once I know what it's all about myself and once it has stabilized to some degree. Secondly, I will look at all the questions asked above about this new functionality for blue blocks and try and give answers. Thirdly, the question about refactoring in blue blocks is not something I knew about so I'll try find out what's going on. Thanks again for your questions.
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.