Latest @
Forum Controls
Spotlight Features
The Rich Engineering Heritage Behind Dependency Injection
Andrew McVeigh takes us on a tour of the rich heritage behind dependency injection, what it represents, and tells us why its here to stay.
Java, the OLPC, and community responsibility
The "One Laptop Per Child" project has a great device ready to ship, but there's no Java on there. Let's think about working together to put Java on OLPC!
Matisse Killer? Riyad interviews the Eclipse VE project leads
URL: EclipseZone Callisto Podcast Series - Episode 2
At 2:36 PM on Jul 5, 2006, Matthew Schmidt
wrote:
Grab the new episode from any of our easy methods:
Direct MP3
iTunes
Podcast RSS at Feedburner
Text Transcript
19 replies so far (
Post your own)
Re: Matisse Killer? Riyad interviews the Eclipse VE project leads
I suspect in the text transcript, the word should be 'Visual Age for Java' and not 'Visual Aids for Java'; the former being a suite of Visual Age for Xxx products that IBM shipped.Alex.
Re: Matisse Killer? Riyad interviews the Eclipse VE project leads
i'd really like to see an intro/how-to screencast for this. my brief 10 minutes or so were fruitless, and i dont feel like taking hours...10 minutes with the matisse interface and i had a working swing app..
Re: Matisse Killer? Riyad interviews the Eclipse VE project leads
Matisse Killer? Sorry, my answer is no.I downloaded Eclipse and all the Callisto projects yesterday and played with the Visual Editor to create a simple GUI application.
It works, but my first impression is that it's a bit less user-friendly than Matisse. But the main reason I like it less than Matisse is this: it generates very ugly Java code!
Look at the way Matisse generates code: it hides all the GUI setup code neatly into an initComponents() method. When you add an event handler to for example a button, it generates a method in your class to handle the event, and keeps the action listener stuff neatly hidden in the initComponents() method.
The Eclipse Visual Editor generates much more messy code: it generates an initialize() method to setup the GUI, but it also generates get...() methods for every component. If you add an event handler to a button, it adds the action listener stuff to the get...() method for the button, and I have to edit the ActionListener there.
I like the way Matisse hides and separates the GUI setup code from the code that I'm going to write by hand much better - I hope that in the future the Visual Editor is going to get better in this regard.
Re: Matisse Killer? Riyad interviews the Eclipse VE project leads
Jesper,What's beautiful to one person is ugly to another. In my experience, Matisse (with its locked areas for editing) is vastly more ugly than code that I can edit and do anything with.
The Eclipse VE uses the same techniques for editing code that Visual Age for Java had since its inception. So I don't expect that it will go anywhere else. The rationale behind having each component being initialised in a get() method is that it allows you to isolate the components and add per-component set up in one place, rather than lumping it all together in one massive editing code block. It's easier to refactor and move that way, for one thing, because if you wanted to move everything out into a panel then you have a subset of methods that can be grouped and moved instead of cut'n'paste in a single place.
It can also make for some readable code, especially when you have routines that need to access the contents of the variables -- the widgets are accessed via their accessors, in much the same way that any decent encapsulated object uses the accessors instead of direct field access to obtain work. But instead of having a separate method to initialise the contents, it's done lazily using lazy instantiation. (It's also quite a good place to identify where to add embellishing features to a widget.)
One trick to keep code manageable is to use nested components instead of one uber-grid layout that you tend to find with the worst code. That way, you edit your application in small units, and then combine those panels into a larger VE bean. This technique works to improve code regardless of how the code is realised in the body.
Anyway, my post wasn't to say that there's a right way; only that beauty is in the eye of the beholder, and there's good reasons for wanting to do it this way.
Alex.
Re: Matisse Killer? Riyad interviews the Eclipse VE project leads
Alex,We do use the old VisualAge for Java coding style on generate for Swing. For SWTwe use a different style, where each composite (think JPanel) has its own initialize method and the controls (think JComponent) that are its children get initialized in the same parent method.
For Swing we just never got around to changing the top down style, although for parsing we read lots of different patterns including, for example, the one used by JBuilder with a big jbinit() method or NetBeans, again with a big initialize method.
For Swing what pattern would you like to see the default on generation ? I personally don't like a huge method that everything gets added to, but then I also can see why having one method per JavaBean is possibly excessive. Maybe one along the lines we used for SWT, where each JPanel (or thing that can own JComponents such as JSplitPane, etc...) have their own initialize method and all the children of theirs get done in the same method. Or would you prefer a huge method everything gets added to ?
I've opened a bug to track this https://bugs.eclipse.org/bugs/show_bug.cgi?id=150232
Please give us your input and ideas and we'll try to spec out a way to be more friendly.
Best regards,
Joe
Re: Matisse Killer? Riyad interviews the Eclipse VE project leads
Hi,Try some of the resources on http://www.eclipse.org/vep/WebContent/docs/doc.html, including http://www.eclipse.org/vep/WebContent/docs/demos/custom_field/FieldBean.html
that is a screen show with Gili talking through building a simple GUI.
Best regards,
Joe
Re: Matisse Killer? Riyad interviews the Eclipse VE project leads
Personally, I like adding a method for every JavaBean. I think it's well structured, and a lot more manageable than having an uber-initialise method. It's also quite good from a naming point of view, because you can have names for each of the fields that you use.Where it starts to break down is when you have a huge component (e.g. everything's in a GridLayout or a SpringLayout) -- but that's more to do with user education about how to design good nested components. Perhaps there should be some documentation about how to design clean UIs.
But like I said, I'm happy with it; it was the OP that had issues that prefered the NetBeans way.
Alex.
audio format request
I'd like to listen to this but I don't use mp3.Can this (and future others) be provided in an audio format that is unencumbered by license restrictions? Perhaps Ogg?
Regards.
Re: audio format request
You'll probably find that you don't want to listen to a discussion regarding a product that has license restrictions, then.Alex.
Re: audio format request
Ok. I'm sorry for being too sloppy. I understand that both eclipse and mp3 have license restrictions. I'll try to be more careful in future. I have no desire to begin an off-topic discussion on license restrictions.However, I accept some licenses and reject others. I noticed that an mp3 decoder is not distributed on SuSE linux; Ogg is. Although I can't claim to be qualified on understanding the license restrictions that make it so, I do recognize there is a difference.
From observation, it appears that listening to this audio requires me to accept a greater restriction than using the software of its topic. Can I be free to listen to a talk regarding use of (license restricted) software without being required/coerced to accept greater restrictions for the audio itself?
Can these audio be made available in the Ogg format?
Re: Matisse Killer? Riyad interviews the Eclipse VE project leads
Ok, I understand it's a matter of personal preference whether you want one big initialize method or not.I don't like generated code. Generated code almost always looks differently from how you would have written the code by hand. Many code generation tools are one way tools: you create the input for the tool (by using the visual editor, for example), run the tool, and use the code that comes out of it. If you modify the generated code by hand, the code is not in sync with the input for the tool anymore.
I understand (also from the podcast) that VE isn't just another one way tool like this, but: it does require me to edit the generated code, and it does impose restrictions on how the code for my GUI is structured. I have to keep myself to that structure, or it won't work.
The reason I like the big initialize method is because it hides all the generated stuff from my view. I don't want to see the generated code, I don't need to know how it works and I don't want to touch it. In Netbeans, the big initialize method is by default folded, so I don't have to look at it. In Microsoft Visual Studio, it works even better: in C#, you have partial classes. When I create a new form class, Visual Studio creates two files: MyForm.cs and MyForm.Designer.cs. Each of those contain a class declaration like this:
public partial class MyForm {
// ...
}
The class declarations in both source files together make up the whole class MyForm. All the generated code is neatly hidden in MyForm.Designer.cs and I write my own code (event handlers etc.) in MyForm.cs.
So, ok, I don't actually care if VE creates one big initialize method or a whole bunch of methods, but what I do care about is that I want to keep my own code separate from the generated code. It would be nice if VE would have a bit more support for keeping the generated code separate from my own code.
Jesper
Re: Matisse Killer? Riyad interviews the Eclipse VE project leads
What about using the VE to generate the superclass, and then write your code as a subclass? You can then add/override methods that you need to, and you'll get the clean separation between automatically generated code and your own contributed code. I agree that in most cases, you don't want to see it, and that you shouldn't need to care. I personally don't use code folding; I just use 'show selected element of source' which means that I only look at the method I have selected.I think that in general, the problems you raise will be present in any tool that generates code. And regardless of which tool you're using, there will be constraints that you can (or can't) live with for each one. For me, the fact that NetBeans prevents editing of the generated code is a worse issue than where/how it generates code, which is why I don't use that myself.
Alex.
Why Code generate? Why not serilize to XML and load at run time.
Why not do something like Glade for Gnome. Instead of code generation serilize the form to XML then load the form from the XML at run time. This is something I would really like to have.Re: Why Code generate? Why not serilize to XML and load at run time.
Hi David,XML serialization is something we have looked at but so far been unable to finalize on a spec for doing. We were actually involved on JSR 75 "long term persistence of JavaBeans" which was designed in part to be an interchange format between visual editors. It has been to a certain extent supceded by the fact most editors read each other's source but XML serialization is still a good goal to have.
The problem is first, what format to use. SWT has XSWT which seems to be a good format, and for Swing there is SwingXML, JSR75 (XMLEncoder/XMLDecoder) that seem good formats. What persistence format do you think would be a good one to use ?
Best regards,
Joe