Wednesday October 31, 2007
Wednesday October 31, 2007
New Version of Groovy Support in Plugin Portal
If you go here in the Plugin Portal, you'll find I've uploaded a new ZIP file, called groovynbms-4.zip (the previous one was called groovynbms-3.zip). In other words, when you click the Download button, you will get groovynbms-4.zip. This time you will have five modules instead of three and this time each of them has a description, as indicated here:
Please make sure to be using NetBeans IDE 6.0 Beta 2. If you're using something later (like a daily build), it might still work (and it probably should still work), but no promises. Once you've installed, you'll find a new category in the New File wizard, with various Groovy file templates:
Once you've created a Groovy file template, you'll see it has the same icon as Java source files. There's also support for the Java parts of Groovy, as indicated below:
The Groovy parts of Groovy are not supported by code completion. In other words, for example, there's no code completion for Groovy-specific things, just Java-specific things. (Where Groovy doesn't support something provided by Java, you'll still find code completion, etc, working for you, you'll just end up with compilation or runtime problems later. But these situations should be minimal.) You'll also find Java code templates working for you (e.g., type ir, press Tab, and then you'll have import). Plus, you'll find the extension to the Java Application project type for running groovyc and Groovydoc from Ant, as described in an earlier blog entry. And when you look in the Library Manager, you'll find the Groovy Library there (had to be a snapshot of 1.1, otherwise the Groovydoc script won't work).
Sometimes the Run menu item, in the editor, is disabled. Especially when you've first started up the IDE or first opened the editor. If that happens, you need to do something in the editor (e.g., add some code and save it) to enable the menu item. Again, no need to download the Groovy installation, because everything should be handled for you by the JSR 223 implementation. Feedback welcome.
The sources are available here: http://nbgroovysupport.dev.java.net/. Anyone is welcome to take them and add to them.
Oct 31 2007, 10:55:54 AM PDT Permalink
8 Comments
Tuesday October 30, 2007
Groovy DSL
InfoQ has a great (i.e., entertaining, interesting, and pragmatic) interview with two Domain Specific Language (DSL) developers, here. I highly recommend watching it. In that interview, Ruby is used to define the DSL, but Groovy can also be used for this purpose, for which all the related resources can be found here. But, I wanted to really understand what all of this is about, and even though the sessions on this subject at the Grails eXchange were helpful, it wasn't until I followed the steps in this blog that I began to really "get it". At the end of it, you can calculate distances and measurements and compare them to each other, using a brand new notation defined in Groovy DSL. So, as one can see in the editor below, it is possible to use the DSL to type '1000.m.km' and, because of your DSL, Groovy is able to understand that what you are actually saying is: "Convert 1000 meters to kilometers", such that it correctly resolves it, as shown in the Output window below:
Note that, in Groovy, "1000.m.km" doesn't mean anything at all. In fact, the Groovy file would have thrown a runtime error, if I had typed that string without specifying the DSL that I wanted to use to interpret my string.
All this is pretty cool to see in action. Basically, what you're doing is extending Groovy. Now it makes real sense to me and now I can begin reading the theoretical stories and the slides from various presentations. Having a complete, working sample is the beginning of knowledge.
Oct 30 2007, 10:50:51 AM PDT Permalink
Monday October 29, 2007
Groovy on the NetBeans Platform!
A first experiment—I created a module suite, added a library wrapper containing the Groovy JAR, another library wrapper containing the JAR of the Groovy-Java-mixed application I created earlier, and then a new module with a TopComponent that calls the Groovy class in the aforementioned Groovy-Java-mixed application. This is exactly how one works with web service clients on the NetBeans Platform (i.e., create the JAX-WS client stubs in a standard Java application and then wrap that JAR in a library wrapper module which is then attached to a module suite that contains another module which calls into the JAX-WS library wrapper). In this case, the ported application has the following result:
The most perfect way of working with Groovy on the NetBeans Platform would be to abandon Java source files altogether and to write purely in Groovy files. (Since Groovy is a superset of Java, one could then still continue writing Java, but one would then have the option of writing in Groovy as well.) I tried this, but haven't succeeded yet. Related to this, here's my contentious statement of the week (and it is only Monday): I don't think NetBeans IDE needs a Groovy Editor at all. It "simply" needs its Java Editor to support Groovy...
Oct 29 2007, 05:40:39 AM PDT Permalink
Sunday October 28, 2007
Groovy on the NetBeans Platform?
Using the script referred to yesterday, with some modifications by Bernhard (see the comments in yesterday's blog entry), I added a JFrame, which feeds the values to the Groovy script as follows:
Scanner scanner = new Scanner(); scanner.scan(folderField.getText(), extField.getText(), searchField.getText());
The lines above are everything that is found in searchButtonActionPerformed. And here's the result, showing the source structure, running application, and output in the IDE's Output window:
And then I generated some Groovydoc, which clearly shows that my Groovy and Java are equal partners (since, in fact, they're both Java):
Well, this is all obvious since, as Jeremy Rayner says in his Javalobby interview, "Groovy is just an implementation detail of your Java APIs". In this context, I'm seeing Groovy more as a programming style than a separate language. In the same way as you can choose to use generics, if you like, or not, you can choose to use Groovy, or not. But at the end of the day you'll still have Java and your user will not care whether you've used generics or whether you've used Groovy. It's just an implementation detail.
Next, it would be interesting to port this to the NetBeans Platform. Is there anyone out there who is using Groovy on the NetBeans Platform? That would be a cool thing to play with and should be completely possible.
Oct 28 2007, 10:40:16 AM PDT Permalink
Saturday October 27, 2007
Scripting for Something in HTML Files
A script in Groovy for pulling all lines with HREF attributes from all HTML files within a folder, as well as all of its immediate subfolders. I call this script from a Java class, as explained in a previous blog entry. The result is that the Output window is then populated with all lines containing an HREF attribute:
Here's the script, could probably be a lot better, especially the part where the next level is found:
package demojavaapplication
class HelloWorld {
def basedir = '/home/geertjan/ijc/htmlfiles'
def text = []
void main(args) {
new File(basedir).eachFile { f->
if (f.isFile() && f.toString().endsWith("html")) {
writeTags(f)
} else if (!f.isFile()) {
basedir = f.toString()
new File(basedir).eachFile { fNext->
if (fNext.isFile() && fNext.toString().endsWith("html")) {
writeTags(fNext)
}
}
}
}
}
String writeTags(f) {
println "--------------"
println "File: " + f.getName()
f.eachLine {
ln -> if ( ln =~ 'href' ) {
text << "${ln}"
}
}
text.each{ println " Found: $it" }
text.clear()
}
}If someone can help to make this script more compact, I would be happy to hear about it.
Oct 27 2007, 01:10:04 PM PDT Permalink
Friday October 26, 2007
Generating Ant Targets for Groovy Compilation and Groovydoc
Jeremy Rayner's interview on Javalobby, where he talks about Groovydoc and the related Ant task, got me thinking about a simple extension to the Java Application project type. Extending existing project types is possible from 6.0 onwards, as explained in this tutorial. So I added a new panel to the project customizer for Java applications, which looks as follows:
Assuming both checkboxes are selected, the user now has (assuming OK is clicked) two new Ant scripts in the nbproject folder:
Let's look at each of them. Here's exactly what you get:
And now you need to add those JARs (in the case of the Groovydoc script, you need a snapshot build, since it isn't supported yet officially) and then simply use those Ant scripts. It would be really cool if they would be linked into the main build.xml, automatically, in the same way as the build-impl.xml is. However, I am not sure if that is possible to do automatically. Although, actually, I think I've done something similar before. I need to investigate that.
At any rate, I will add the sources of the module that provides this functionality to http://nbgroovysupport.dev.java.net/.
Oct 26 2007, 02:37:38 PM PDT Permalink
Thursday October 25, 2007
Groovy in Plugin Portal
I've been squirriling away some Groovy editor support for a while. Today I put it all on a site I had requested sometime ago. It's not necessarily much, but gets the job done, basic syntax coloring, a file template, and a run script action via JSR 223 (hence you need JDK 6). Go here:
http://plugins.netbeans.org/PluginPortal/faces/PluginDetailPage.jsp?pluginid=3914
I intend to continue squirriling, bit by bit, as time goes by. But there's definitely enough there already for the absolute basics. After installing the three NBMs in the ZIP file referred to above, you'll have a file template:
When you finish the wizard above, you'll be able to run scripts (right-click in the editor and choose Run Groovy Script), with the results typically in the Output window:
By the way, using the technique shown a few days ago, you can continue stepping through Groovy to your heart's content:
If you don't like the fonts and colors I chose for you, go to the Options window, to the Fonts & Colors tab, to change them:
Use these three NBM files at your own risk. Possibly it will destroy everything you've ever believed in. Or maybe just your IDE, which is probably worse. So be careful. It has not been tested, I created it on a post-6.0 Beta 2 build on Ubuntu, so possibly you won't even be able to install it. I would be interested to know what people think of it.
Oct 25 2007, 04:50:39 PM PDT Permalink
Wednesday October 24, 2007
Untyped Variables in Groovy and the NetBeans Debugger
When I blogged about stepping through Groovy recently (here), Peter Williams left this question in the comments: "Are groovy variables typed and/or can their type change dynamically (e.g. x="foo" followed by x=1 being legal, though the type is changing from string to integer?) If so, is the NetBeans debugger displaying this change properly?"
Well, today I had a look, curious to see what would happen. Here's my Groovy script, with a variable called "thing", which is first defined as "Tom" and then later as "50":
First, once we've stepped past the first definition, the debugger shows us the correct value as well as the type:
Next, it does the same for the number:
Pretty cool. Untyped variables in Groovy are correctly reflected according to type in the NetBeans debugger.
Oct 24 2007, 04:49:44 PM PDT Permalink
Tuesday October 23, 2007
Eclipse + NetBeans = Groovy
One of the absolute highlights of my trip to the Grails eXchange last week was... hanging out with Scott Hickey, the main developer of the Groovy plugin for Eclipse. Here's a pic of us in a bar after the first day at the conference; you can't see all the other people around, nor the Black Sheep beer (because I think we were still waiting for it) and the reason that the pic is so grainy is that I couldn't get my flash to work, which was because I had my camera set to 'movie' instead of 'photo', so that I now have a few very short movies, from which I cut the pic below, Scott on the left and me on the right:
It was very cool to talk about Groovy and plugins and IDEs, Scott's insights (as recorded in this blog last week, about debugging Groovy via the Java debugger and about compiling and running Groovy via Ant in NetBeans IDE) were just really practical. Thanks Scott, hope to meet up again soon!
Oct 23 2007, 05:58:05 AM PDT Permalink
Monday October 22, 2007
JFugue Music NotePad: Why Not Join This Project?
As of today, the JFugue Music NotePad is running on JFugue 3.2. It continues to be based on NetBeans IDE 5.5 (or NetBeans IDE 5.5.1), however, so don't make the mistake of trying to open the project in some build/milestone/beta release of NetBeans IDE 6.0! Once you have it running (which should be possible without a single hitch, after checking out nbjfuguesupport from dev.java.net), you should be able to compose music, with results similar to this:
The latest enhancements ensure that it isn't possible to drop more notes into a measure than the number of beats supported by the sheet. So if 4/4 is specified, one cannot put more than 4 full notes into a measure, for example, plus an error message appears if the next note you're dropping would cause the measure to exceed the specified beats. Other related fixes include a correction in the note stem direction, the rules of which state that the stems of all notes below the middle or 3rd line from the bottom of the staff should point up and the stems of those that are above the middle or 3rd line from the bottom of the staff should point down. Yes! This is the level of detail that the application has attained. Thanks a lot to M Valeri for these latest enhancements.
As specified on the related website, the application currently lets you do all of the following:
- Create new music sheets. Choose File | New to create your first music sheet. A wizard appears, make your selections, and click Finish. You now have a music sheet. You can create multiple music sheets; all actions you perform apply to the current music sheet.
- Add notes to the music sheet. Click a note in the toolbar, set (if applicable) whether a sharp or flat should be applied, and then click the music sheet. You have now added a note to the music sheet. The application prevents you from adding a note if doing so would result in the added note exceeding the number of beats in the measure, as shown in the screenshot above, via a red message in the toolbar.
- Change notes. Select one or more notes with your mouse. Notice that the selected notes are now red. Now click the Up arrow and Down arrow to move the notes up and down. Click the Left arrow and Right arrow to increase or decrease the duration of the selected notes.
- Delete notes. Select one or more notes with your mouse. Notice that the selected notes are now red. Now click the Delete key and the selected notes are deleted, while the remaining ones are redistributed.
- Change instruments. Right-click an instrument in the Instruments window (if it is not open, go to the Window menu to open it) and choose Select. You can also choose Sample, to hear a sample of the instrument. Now, all notes dropped after you selected the instrument will be played by the instrument.
- View JFugue music strings. Open the JFugue Commands window and notice that all the instruments and notes that you have selected have been generated there, with helpful syntax coloring. There is no need for you to understand these strings, that's why you're using this application in the first place!
- Print music sheets. Choose File | Print. A Preview appears, from which you can print. You might need to resize the application a bit, because the size of the current music sheet determines the length and breadth of the print output.
- Play music. Click the Play button in the sheet's toolbar and the current music sheet is played.
- Save music. Click the Save button in the sheet's toolbar and the current music sheet is saved.
- Add plugins. If/when plugins for the application become available, simply choose Tools | Update Center and then use the Update Center wizard to install the plugins.
For a partial history of this project, see Real World Guide to Open Sourcing a Saturday Project on Javalobby. Anyone at all is more than welcome to join the project, it's proven to be a fun application and the threshold for participation couldn't be much lower. Just pick something that you think the application should be able to do, make sure that it isn't already in Issuezilla with someone working on it, and then just go for it. State your intentions in Issuezilla or in the developer's mailing list and then go ahead and make it do whatever you think would enrich the application.
Oct 22 2007, 09:43:19 AM PDT Permalink
Sunday October 21, 2007
Installer Generator Creator: Vadiraj Deshpande
Vadiraj, and his team in Bangalore, have been working on the openInstaller, which is a framework for creating cross-platform installers. The NetBeans Application Installer Generator can be seen as the reference implementation of the openInstaller project. You can use it to create an installer for your NetBeans Platform applications, such as this one for the Feed Reader, which is one of the samples bundled with NetBeans IDE:
Check out the the Wink screencast, which shows how the above was created.
Below is an interview I did with Vadiraj about his work and interests in relation to the NetBeans APIs:
Hi Vadiraj, who are you and where do you live? I am Vadiraj, living in Bangalore, which is soon to be renamed "Bengaluru"! I work for the Enterprise Java Platform Group in Sun Microsystems. We're designing and developing an installer for the Java Enterprise System Product stack, which includes Enterprise products, like the Sun Java System Portal Server, the Sun Java System Access Manager, as well as application containers such as the Sun Java System Application Server and the Sun Java System Web Server. The installer helps customers to install and configure these products together.
What's your connection with the NetBeans Platform? Well, frankly it is my favorite toy these days! We are developing a new enterprise grade installer framework called "openInstaller", which was open sourced recently and is freely available at http://openinstaller.dev.java.net. In this, I am involved in developing an IDE for assisting in the development of installers op top of the openInstaller framework. It is far from complete, but it will be able to help you in creating a basic installer which you'll also be able to extend a bit.
I am also working on another plugin which is called NetBeans Application Installer Generator, NAIG, for short, which adds support for installer creation to NetBeans Platform-based applications. This can be used by NetBeans Platform application developers to create installers for their standalone module suite projects.
What is this openInstaller exactly and what was the motivation behind it?
openInstaller came into existence to address some of the issues that we were facing during the previous version of the Java Enterprise System. Here is a summary of the features:
- This framework is written from the ground up and has a different architecture and design from its predecessor.
- This installer enables non-root installation, multi-install-home installation, like installing multiple copies of the same product on a single box, keeping them separate.
- Multiple mode support, where the installer can be executed in GUI, commandline (CLI), and in silent mode. This framework abstracts all these modes from the core framework and user code.
- The framework provides declarative UI support, where we just tell the framework what UI fields we need in a simple XML file and it creates those UI fields in the mode (GUI, CLI or silent) in which the installer is running.
- openInstaller provides robust configuration support for install time configuration of products, with heartbeat feedback support. What this means is that products can have their own way of configuring themselves and when the installer invokes the individual configurations, there's a feedback mechanism provided to configurators so that they can tell the installer about their progress.
- The openInstaller supports cross platform installer generation (one installer for all platforms, or one product bundle for all platforms).
- The installer is fully skinnable and hence it is easy to brand the installer.
- The openInstaller received a few advanced features recently, which include product selection panel support (which allows to have interconnected products in a product suite installation) and upgrade support (both from legacy and openInstaller supported).
What are some of the modules or applications you've developed on the NetBeans Platform? I wrote many small modules while I was learning about module development on the NetBeans Platform. Right now, I am involved in developing the openInstaller IDE. In fact, after reading many tutorials, blogs and articles about NetBeans module development, I started module development with a scratchpad application, which is similar to what is described in the RCP book. It was very easy for me to learn module development by actually writing my own modules.
I am also involved in promoting the XML Multiview API, which is a powerful but little-known API of the NetBeans Platform. This API allows creation of visual editors for any schema or DTD defined in XML. Considering that XMLs are everywhere these days, this API has lot of untapped potential. If anybody wants to use it or is already using it, I would request them to vote for this issue, which aims at stabilizing this API.
Tell us about some of your experiences... which APIs have you used? NetBeans module development is very interesting and challanging, both at the same time! The interesting part is you get to code exactly what you want. You are able to focus on your application requirements, rather than on the development of a lot of boilerplate code. Learning module development, NetBeans Platform APIs are easy and most of them follow in a natural way. For example, often, if you are thinking about a method which you might be expecting to be present somewhere, using well defined design patterns, you will see that it is there!
...and which are your favorites and what are the problems you've encountered? My current favorites are XML Multiview API and Visual Library API. Both APIs are used in the openInstaller IDE.
- The XML Multiview API, although it seems to be complex the first time round, is a powerful API and provides a framework to develop visual editors for any kind of XML file with a well defined DTD or schema. Think about writing editors of this kind on your own... it would be a separate application development process all on its own. The API makes it so convenient to develop visual editors, with many pages (multiviews) and many sections inside them. You decide how you want to divide your XML files and how each part should be represented. And its very easy to provide multiple perspectives for a single part too... as I wrote in my blog.
- The Visual Library API is so easy to use and easy to learn too. We can create graph and tree-like structures easily and make the nodes moveable using just a single method. No repaint issues. No messy graphs.
I see the XML Multiview API is used in the development of the Visual Editor for web.xml files and the Visual Library API is used in many modules, such as the Visual Web Pack. During the initial period, developing on top of the XML Multiview API was difficult. There was less documentation except your tutorial-blog about the Book Example. As this API is not yet public, there is no published Javadoc available. But later, the API with its powerful features, overcame all these problems.
Can you give us some tips, especially in relation to actual code snippets as illustrations? One thing I am amused about in relation to NetBeans modules is the way they are designed with modularity in mind. While being separate from each other, you have a key to combine them or use one in another module. For example, in the NetBeans Application Installer Generator plugin, when the plugin finds that the current module suite project is not yet configured as a standalone application, we wanted to provide the option to the user to set this. But the project customizer for module suite projects is created really deep inside the apisupport/project module and the whole apisupport module is private... phew! What were we to do?
Here comes the beauty of NetBeans modules... You can use what's available to you which is in common to your module and the other module. Lookup to the rescue! The module suite project carries an interface called CustomizerProvider in its lookup. and this Customizer has one method called showCustomizer(). So all the code for invoking the project customizer from an arbitrary module for the module suite project, which is in fact created by a private module, is like this:
Project moduleSuiteProjectHandle;
...
...
...
CustomizerProvider customizer =
moduleSuiteProjectHandle.getLookup().lookup(CustomizerProvider.class);
customizer.showCustomizer();
Just three lines of code does the trick! You need to take a look at that plugin to really see this in action.
What do you think about NetBeans IDE? Great IDE with cool features. There is a lot to learn and one can see some interesting things as they happen. For example, the NetBeans GUI builder is really cool. When I moved from Visual Basic to Java in late 1995, I was looking for such a thing available for Java. Glad that now it is there! The new NetBeans 6.0 Schliemann Project makes supporting new languages very easy. And the other features, like the Visual Library API, and all the recent new scripting language supports, are giving NetBeans IDE the required edge to get ahead of the competition.
Is it useful in developing NetBeans modules? Which parts in particular? Yes, of course. NetBeans IDE comes with all sorts of goodies that one can use to develop applications which need less plumbing work. Being modular in design, it can easily be extended to support new features easily. The "apisupport" module, which provides tooling support, goes way beyond a simple level of helping NetBeans module developers with lots of wizards and templates.
Have you used 6.0 builds at all? What are your thoughts? I have been using NetBeans IDE 6.0 Beta 1 since its release, and it looks really great... the new theme and the new features specially the scripting languages support for Groovy and Ruby. It comes with the right tagline, in my opinion: "The only IDE you need".
If there is one thing NetBeans should improve, it would be... to improve tooling support for NetBeans Platform development. Robust JNLP hosting support, and update center descriptor creation for individual modules, are some I can think of. Hope to see some more in the coming period.
Any final thoughts? Well, NetBeans rocks! All the community members, you and Roumen, and so on, are doing a great job in keeping the IDE in sync with the new developments. Thanks for all your hard work and keep up the good work. Plus, I would like to request the community to try out NetBeans Application Installer Generator to build installers for their module suite applications and send me your feedback. Go here to get it. I am also looking for contributors to improve this plugin further, ideally to extend this plugin to support installer generation for Java Projects inside the IDE, creating installlers with bundled JDK, and some other similar cool features. Ideally, I am looking for people who have core Java and XML skills apart from NetBeans Platform knowledge.
Oct 21 2007, 03:46:57 AM PDT Permalink
Saturday October 20, 2007
Featured Book in Second Life
Second Life is featuring the Rich Client Programming book:
Thanks for the info and pic, Vadiraj! An interview with him about his amazing installer generator is coming soon, so watch this space!
Oct 20 2007, 05:01:54 AM PDT Permalink
Thursday October 18, 2007
Stepping through Groovy in NetBeans IDE
I put a breakpoint in the Java class I showed yesterday and am now able to step through the Groovy script, with the Local Variables window showing the current state of my Groovy variables:
Funnily enough, Scott Hickey, the main guy behind the Eclipse plugin for Grails and Groovy, is the one who worked with me in (a) coming up with the procedure I outlined yesterday and (b) thinking up the possibility of debugging Groovy, in the way demonstrated above! The Grails eXchange is definitely one of the best conferences I have been to, in terms of people freely exchanging ideas and learning from each other's insights and enthusiasms. The main message I'm going home with is the rather obvious realisation that Groovy is in a completely different category to any other scripting language, because of its relationship with Java. Hence, lots of stuff (such as the Java debugger, as indicated above) can simply be reused when working with Groovy. That insight should also inform the tooling provided for Groovy. The closer we stay to Java, the more we can get from it, the less we'll be reinventing the wheel, and the greater the chance that we'll be providing something truly useful for Groovy users in NetBeans IDE.
Oct 18 2007, 03:26:14 AM PDT Permalink
Wednesday October 17, 2007
Compiling and Running Groovy from Java in NetBeans IDE
Something I learned today at the Grails eXchange here in London. Without any plugins at all, you can already call Groovy scripts from Java code in NetBeans IDE, as outlined below.
- Start by creating a small script called "HelloWorld.groovy", using the "Empty File" template to create the file, with this content:
package demojavaapplication class HelloWorld { static void main(args) { println "Hello from Groovy!" } }Now, we will set the project up so that the above will be called from a Java class in our application.
- First, here's an Ant script, added to my build.xml, that runs the Groovy compiler:
<taskdef name="groovyc" classpath="lib/groovy-all-1.0.jar" classname="org.codehaus.groovy.ant.Groovyc"/> <target name="-pre-compile"> <groovyc srcdir="${src.dir}" destdir="groovy"> <classpath path="lib/groovy-all-1.0.jar"/> </groovyc> </target> - Now, to use the above Ant script, do the following:
- Right-click the Libraries node and add groovy-all-1.0.jar from the embeddable folder in the Groovy distribution. Now create a folder called "lib", in the Files window, and put the JAR there.
- In the Files window, create a folder called groovy and add that folder to the Libraries node, which puts it on the classpath.
You now have set "groovy" as your destination directory for the Groovy compiler. You have added the JAR that provides the Groovy compiler. You have added the "groovy" folder to the compile time classpath, so its content is compiled, prior to compilation of the Java classes.
- When you build your application, you should now see this, while taking note of the fact that your Groovy script is now a Java class:
- Since your Groovy script is now a Java class, and the folder that contains it is on the compile time classpath, you can call it from a Java source file:
public class Main { public static void main(String[] args) { HelloWorld hello = new HelloWorld(); hello.main(args); } }Plus, you have code completion from the Groovy script available to your Java class.
- Run the application and you have "Hello from Groovy!" in the Output window.
Oct 17 2007, 08:42:43 AM PDT Permalink
Tuesday October 16, 2007
Quick Code Generation for the NetBeans Platform
A new NetBeans Platform developer wrote to the docs feedback alias, in response to the Recognizing a File Type Tutorial, the following words: "How do we actually change the contents of the new .mf file? what if I don't want it to be in text format? what if I want it to open up a another project X (with its own topcomponent, palette and graphscene) when the user creates a new file type?"
Well, the answer is found in an earlier blog entry entitled Elvis, Einstein, and Advanced NetBeans API Wizards. There you're pointed to two magical wizards that generate exactly the code requested by the developer above! Let's use them to generate the things that the developer asked for above. However, before we do so, some caveats:
- Generating lots of code is not necessarily a good idea, especially if you don't know what you're doing. If you build everything from the ground up, you are far more likely to learn how things work. Also, what happens when you run into some problem when you begin developing your code? There's no way that you're going to easily be able to figure out where the problem comes from if you didn't create it yourself. Okay, you can debug it, but it's not an ideal situation.
- A lot of the code that is generated is my own. So, be careful. On the other hand, most of it is pretty basic code. In other words, you get a very basic palette, a very basic graph scene, a very basic OpenSupport implementation. So, all things being equal, the code should be good. On the other hand, all things are never equal.
At the end of this process, whenever you create a new Manifest file in NetBeans IDE, the Manifest file will have two views. The source view will include a palette (Common Palette API), while the design view will include a graph scene (Visual Library API), as shown in the next two screenshots:
You'll be able to drag and drop the palette item into the source view. To do so in the design view, you will need to follow the NetBeans Visual Library 6.0 Tutorial once you have completed this process. Your module's source structure will be like this:
However, again, you've been warned about the problems you might encounter. Still, it's at least fun to do, even though there are one or two transitions that are a bit clunky, as you'll see.
- Download the plugin from the Plugin Portal.
- Use the Plugin Manager to install the plugin into NetBeans IDE 6.0 Beta 1 or some other 6.0 build. Now go to the Samples | NetBeans Modules section. You will see two new modules, "Enhanced File Type" and "Enhanced Window":
- Complete the wizard for one of them. Then complete the wizard for the other one. The order is irrelevant. Then right-click one of them and choose "Install/Reload in Development IDE". Do the same for the other one. Again, the order of doing this is irrelevant.
- Create a new module project. You're going to get lots of code, a variety of classes, lots of new layer entries and Bundle keys. Therefore, better to begin with a completely new module than to try the following steps with an existing one where you already have code. So, create a new module project.
- In the New File wizard, you will now find two new file templates, "File Type (Enhanced)" and "Window Component (Enhanced)", as you can see here:
- Choose the first one, i.e, "File Type (Enhanced)". You will now see this:
- Fill it out for your file type, specify some sample content for the palette item that will be created, specify whether the document should open in a TopComponent and name that TopComponent (and just ignore the fact that some parts are greyed out, because they shouldn't be greyed out):
- On the next page, you will see everything that the IDE is about to create for you:
- Click Finish. Now the IDE creates everything in your module project. However, the TopComponent that you named in the wizard doesn't exist yet! So, you have some red error marks in the class that will handle the opening of the document for you:
Next, we'll create that TopComponent! But, it won't be a standard TopComponent. No, it will be a multiview component with a graph scene in the visual view. The next steps are all about how to do this via the other enhanced wizard.
- Choose the other enhanced wizard:
- Fill it out and notice that you cannot select all checkboxes at the same time, because some contradict the others. For our purposes, we'll specify that we want a multiview editor (an implementation of Core MultiView, not XML MultiView, by the way!) and a Visual Library API implementation:
- Click Next and then finish the wizard. Now you have two data objects. That's unavoidable, because we needed to create one during the second wizard, to work with the multiview. You also have an error badge over the new one:
So, now... you're going to have to (1) delete "ManifestDataObject" and then (2) rename "ManifestDataObjectSample", so that it is called "ManifestDataObject" instead. Sorry, this is messy. It would not pass any kind of review process, but they work and they get the job done.
- That's it. All the code is complete, all the layer entries are present, all the Bundle keys are there, all the project dependencies have been set. You should see this:
You might still encounter some error badges, but you'll notice that you can compile the module without a problem. Install it and you'll have a multiview editor with a palette and a graph scene for Manifest files.
Now, you need to learn from those sources. The vast majority comes from reliable places, for example the OpenSupport implementation is completely standard. It handles the opening of your Manifest documents, such that it opens into your new TopComponent. Now go to NetBeans Modules and Rich-Client Applications Learning Trail and look especially at the tutorials under the heading "New! NetBeans IDE 6.0 Beta Tutorials".
Oct 16 2007, 08:09:33 AM PDT Permalink