Community
Participate
Working Groups
In VisualAge for Java on the Create Class wizard the user could select whether they wanted to use the VCE or not ( using a check box called "Compose the class visually" ). For WSAD we have an editor registered against .java calleld "Java Visual Editor". Rather than make this the default ( because the user could create EJBs, servlets, and then create some GUI classes ) it would be nice if on the Create Class wizard it checked to see the number of editors registered against .java. If there is >1 then show them to the user in a checkbox list with the default one selected ( which is the Java Editor ) and let them change to the other one ( in our case the Java Visual Editor ). Without this the user has to do Create Class and then close the Java Editor and re-open with our editor.
This is actually a good point but for 2.0 we are in a mode where we only consider critical bug fixes. Postponing > 2.0
This is quite a nagging problem for a Java Visual Editor user. It would be one of the things would make a great difference in 2.1. It will be also helpful if one could invoke the class creation wizard, biasing it to choose a given .java editor and possibly an inheretent class. This will not require a user to actively choose, if the action was specific, e.g., create an Applet (where the bias will be set for the Visual Editor, and extending the java.awt.Applet class).
I noticed that in WSAD there is now a special wizard for creating a visual class. This wizard offers additional functionality over the vanilla class wizard. Therefore, is this still a nagging problem for you?
We put the additional wizard there basically because we didn't have the ability to control the editor that was launched following the default Create Class wizard. The only additional functionality that our Visual Class wizard does it to launch the Visual Editor for Java ( our Swing/AWT GUI builder ) and it also lets you pre-select the superclass which is just a nice nugged we put there. We only built the wizard because users didn't like creating a class with the regular wizard and then closing it and re-opening our editor, so the wizard is basically doing a vanilla CreateClass and then driving our editor to be opened. Ideally we want to get rid of our wizard and just use JDT functionality. With the Visual Editor for Java we are trying as much as possible to not create new things but use as much of the JDT tooling as possible and not give the user a new set of perspectives, wizard, etc... to learn. The editor itself reads and write the .java file directly and we actually embed the CompilationUnitEditor in a split pane with the GUI on top. If you're interested to see more there is an article we just published at http://www7b.boulder.ibm.com/wsdd/techjournal/0210_winchester/winchester.html We would like to remove our Visual Class wizard and just have an API so that the regular Create Class wizard is able to let you specify which editor you want to launch if there are >1 registered for .java. Better than that would be that the editor type could be pre-filled based on the superclass selected. Generally if the user subclasses a java.awt. or javax.swing class ( or subclass thereof ) we'd like our editor to be the one selected in the list, however for other classes it doesn't make sense to do visual composition so the default workspace editor should be used. This API would be useful for other people, for example if someone subclasses an EJB class they might want a special EJB editor to be the default one chosen by the wizard. Another thought we had was to try and put our own wizard on the toolbar next to the Create Class one. This isn't possible however, we can create our own action set but it won't look to the user as though it is integrated into the existing Create JDT toolbar actions so it lacks fit and finish. Another thought that might work well is is that the Create Class wizard itself could be a drop down toolbar option ( like the Run and Debug options are ) and the list would include items like "Class","Visual Class", etc... These could be defined in an extension point that specifies things like default editor to use, initial superclass, and additional pages. Then after Visual Class we could pre-fill the superclass and make sure our editor is used but not have to subclass the Create Class editor at all. The next page would let us put any additional options we might want such as questions about the initial size, whether they want a toolbar, etc... This way the user is using the Create Class wizard, they can quickly select they want a Visual Class, and us and other plugin providers can supply customizations in the form of their additional pages.
thanks for additional info - glad that we asked again. Let's us also spend some more thoughts on this - it is as item to be investigated on our 2.1 plan.
Got addressed for 2.1. The create class toolbar item is now a drop down list, into which other plugins can contribute their own items.
