• A design bug in the properties window section,
• Missing the visual library api dependency,
• Excessive overiding the default action on file context menu,

and it would really benefit from some extensions, particularly:

• implementing a navigation window instead of a node tree under the file node,
• real-time synchronisation across all views.

Everything up until the “Creating features for Abc files” stage in the tutorial worked smoothly for me.  This section also works if you follow the instructions carefully (pay attention though folks, I forget to set the content type in the wizard when I did it). There are some misleading statements though, probably left over from earlier versions.  In the first paragraph the introduction says “we enable the file to open into a window, instead of into an editor” but this is not what the action does – it simply raises a modal dialogue window.  The next paragraph, “Adding a context-sensitive Action” then says that the wizard will register the newly generated class in the layer file, however in this version of Netbeans this no longer happens.  Another niggle I have is with the action that’s created. The tutorial suggests we make our action the default action, the action that’s used for a double-click.  This is annoying to me as the double-click action should be “open file in editor” so in my version of this I choose a different location in step 3.

“Creating additional Multiview windows” works just fine.  “Parsing the file” also works but it’s not an elegant solution.  Nodes are created when the file is first opened but then if the file is changed in the editor,  those nodes are not updated. Another niggle I have with this section is that I think it would be better if we saw the tree in a navigation window but I’m not sure how much code this involves.

The “Extending the Properties window” section has a design error in it.  The code provided attempts to preserve the existing file properties but fails because the new default properties set has the same default name.  I would suggest the following variation in the AbcNode class:

public static String SHEET_ABC_PROPERTIES = "abc properties";
 
@Override
protected Sheet createSheet() {
  Sheet sheet = super.createSheet();
  sheet.get(Sheet.PROPERTIES).setDisplayName(NbBundle.getMessage(AbcNode.class, "LBL_Abc_PROPERTIES_File"));
  Sheet.Set set = Sheet.createPropertiesSet();
  set.setName(SHEET_ABC_PROPERTIES); // default is Sheet.PROPERTIES
  set.setDisplayName(NbBundle.getMessage(AbcNode.class, "LBL_Abc_PROPERTIES_Abc"));
  sheet.put(set);
  set.put(new LineCountProperty(this));
  return sheet;
}

with the addition of two new strings in the Bundle file:

LBL_Abc_PROPERTIES_File=File Properties
LBL_Abc_PROPERTIES_Abc=Abc Properties

The Final “Creating Synchronised views” misses the vital information that you need to add the “Visual Library API” library in order to compile, but this wasn’t too hard to work out.  It works fine but the two views are only synchronised when the file is saved and this isn’t what’s described in the text. This lack of real-time synchronisation is further exacerbated by the lack of any synchronisation with the node tree in the project explorer.

To conclude, aside from fixing the niggles I would really like to see a navigation window implementation and better synchronisation between the views, however I found the tutorial as it stands very useful.  And of course it could be that the amount of code needed for my suggestions exceeds the word limit for one of these tutorials.

I’m taking baby steps while I explore the space of possible options.  So far I’ve prototyped an expression evaluator that accepts data in the form of simple Java  framework objects and allows boolean expressions to be evaluated over them. In today’s baby step I thought I’d try and manipulate some non-framework Java objects built with an EMF model that I’m currently working on and two different scripting languages, Groovy and Rhino. Groovy is a scripting language that has grown out of the Java community in response to Python and Ruby.  Rhino is a Javascript engine implemented in Java from the Mozilla foundation that is bundled as the default scripting engine in the Java6 JDK.  I got somewhere with Groovy but got completely stumped with Rhino because I just couldn’t load my custom classes.

Groovy

First the success story.  I fired up the groovy shell (groovysh) in the directory that contains my classes and got started straight away:

Groovy Shell (, JVM: 1.6.0_15)
Type 'help' or '\h' for help.
-------------------------------------
groovy:000> dec = new argkit.decision.impl.DecisionImpl()
ERROR java.lang.NoClassDefFoundError: org/eclipse/emf/ecore/EObject
at java_lang_Runnable$run.call (Unknown Source)

Oh, yeah, I needed to add the EMF classes to the classpath. I could do that by restarting the shell with the EMF jars included in the classpath or add them in directly…

groovy:000> this.class.classLoader.rootLoader.addURL(new URL("file:///.../org.eclipse.emf.ecore_2.5.0.v200906151043.jar"))
===> null
groovy:000> this.class.classLoader.rootLoader.addURL(new URL("file:///.../org.eclipse.emf.common_2.5.0.v200906151043.jar"))
===> null
groovy:000> dec = new argkit.decision.impl.DecisionImpl()
===> argkit.decision.impl.DecisionImpl@5878d2 (name: decision0, caption: null)
groovy:000> cand = new argkit.decision.impl.CandidateImpl()
===> argkit.decision.impl.CandidateImpl@b9132a (name: candidate1, caption: null)
groovy:000> dec.candidates.add(cand)
===> true
groovy:000> cand.status
===> UNKNOWN
groovy:000> arg = new argkit.decision.impl.ArgumentImpl()
===> argkit.decision.impl.ArgumentImpl@ce796 (name: argument2, caption: null) (support: +)
groovy:000> cand.arguments.add(arg)
===> true
groovy:000> cand.status
===> RECOMMENDED
groovy::000> arg.support = argkit.decision.Support.AGAINST
===> -
groovy::000> cand.status
===> REJECTED
groovy::000> exit


Having told Groovy about the EMF jars my code depends on, I create a decision object with one candidate and watch the recommended status of the candidate change with the addition of an argument and it’s subsequent manipulation.

Rhino

Then I fire up the equivalent for Rhino (jrunscript), this time remembering to include the EMF jars on the classpath, and start my shell:

js> dec = argkit.decision.impl.DecisionImpl()
script error: sun.org.mozilla.javascript.internal.EcmaError: ReferenceError: "argkit" is not defined. (<STDIN>#1) in <STDIN> at line number 1

Ah.  This was an unexpected issue as argkit is definitely on the classpath.  And there’s pretty much where I got to.  Some digging lead me to this bug report for Java which suggests that the problem is with the non-standard top level domain name (TLDN) in my package and points the finger at Rhino.  Adjusting my model (by setting .org as the TLDN) for this perplexing issue got me a little further…

js> dec = org.argkit.decision.impl.DecisionImpl()
script error: sun.org.mozilla.javascript.internal.EcmaError: TypeError: [JavaPackage org.argkit.decision.impl.DecisionImpl] is not a function, it is sun.org.mozilla.javascript.internal.NativeJavaPackage. (#1) in at line number 1

Ummm, it’s a what?

js> org.argkit.decision.impl.DecisionImpl
[JavaPackage org.argkit.decision.impl.DecisionImpl]

It’s certainly not a Java Package. It seems to me that Rhino was really not cut for this particular use case.

Conclusions

So to recap, I tried to use Groovy and Rhino to manipulate some non-framework objects, as the expressions in my scripting engine embedded app will need to range over custom state objects and Groovy beat Rhino hands down in terms of ease of integration with the custom code. Now, if only I could get the Groovy plugin for Eclipse to install, but that’s another story…