Of Netbeans form files, Widget macros and Matisse.
Just recently I've been tinkering with my project particularly in the realm of
â€œWidget tweakingâ€. I won't bore you with the details, but suffice to say that
â€œSomething strange happened to me on the way to the repository!â€
Basically I was editing my component source then checking that my changes worked OK in
Netbeans. The problem occurred when I made a mistake in a container class and the IDE
registered it as a component. I investigated the problem, saw my stupid mistake and rectified it.
So having closed my test form in the IDE, I reopened it but, to my dismay, the damn thing was
still not behaving like a container. My first thought was that the class was not being unloaded
by the VM. So I put a bit of code in to fire a message box. This worked, so the IDE was
obviously doing the right thing with class loading (I never doubted it really!) but the thing
was still registered as a sub component.
I then tried adding another instance of my container class and â€œlo and beholdâ€ this correctly
registered itself as a container.Then the penny dropped. I opened the form file in another editor
and sure enough there was my original instance tagged as a component
and my new instance tagged as a container.
Now I'm sure many people will think â€œhow stupid can this guy be?â€ either because they think I
should use Eclipse or simply that I should have known Netbeans would retain the original tag.
Well firstly, as there is only me on this project, making my widgets usable with Eclipse is still
on the â€œto doâ€ list, secondly, I suppose I did know about the contents of the form file but it just
didn't dawn on me at the time. Of course it is, perhaps, an example of why some people do not
like the idea of the form file controlling what happens in the IDE.
I can see there are pro's and con's to the concept of a separate IDE control file, with it the
integrity of the IDE generated stuff is probably safer from inadvertently screwing up by
editing the source in another editor. But on the con side it is another file that must be
maintained and if somehow it got out of sync with the java source ar worse still if it got lost...!
Well it just doesn't bear thinking about.
Anyway, the aim of this blog was not to start another Netbeans vs Eclipse (or any other IDE)
flame war, it's about my fun and games with creating compound components or widgets as I
prefer to call them which leads me to my next point, which is more of a request for comment.
Widget Macros (or Macro Widgets).
Whilst getting confused with the niceties, or otherwise, of Netbeans form files, I started musing
about the problem of compound widgets in an IDE. What I mean is creating a widget
that contains sub components. Obviously the IDE has no visibility to the inner components of
such a compound widget. This can be a pain if you just want to tweak an odd property as you
either have to wrap the required sub component methods in your widget class API or you could
provide access to the sub components with suitable getter methods, but it isn't very elegant.
So what I wondered was, and this could apply to any IDE, would it be feasible to derive a sort
of macro approach where a compound widget could be assembled using the IDE as if it were
a normal form and then saved, in source form, as a macro â€œtemplateâ€ which could be inserted
into a real form at design time, expanded out so that all the inner parts of the widget became
separately visible to the IDE but bound together in some way to prevent breaking the
predefined relationship of the widget's sub components.
It's probably a daft idea, or it's already been done. But I just wondered what anyone thinks?
Also: Matisse and ScollPanes who's in control?
Whilst on the subject of IDEs, or Netbeans in particular. Is there any way to stop Matisse
automatically adding a JScrollPane when you add a Scrollable component?
I couldn't find any way but it could be I never looked in the right place!
The reason I ask is that in the earlier version of my project I had created a JTextArea and a JList
subclass that, at run time, automatically added a JScrollPane as an instance of either got added
to my custom subclassed JPanel container.
Matisse adding its own JScrollPane in such a case was a nuisance as it was not obvious to an
end user that they must remove that JScrollPane. The new version of my widget appears to the
IDE as a JComponent so Matisse ignores it, so the problem has gone away at the moment.
I just wondered if there was an easy fix?
If there isn't, then I would respectfully suggest there should be!
Any automatic feature, no matter how brilliant should always allow the end user to switch it
off if required.
The switch should be a property associated with any form class so that templates can be
created with the feature switched off if necessary. Or, alternatively, it should be possible to
mark a widget class so that the feature was disabled even though the class implements Scrollable.
Just my two pennies worth.
Anyway enough of my ramblings!