Moderator (MDR): SPK-rohaly
SPK-rohaly: Hi, my name is Tim Rohaly, and I'm here today to answer your questions on the MageLang JavaBeansTM Short Course, which can be found at http://developer.java.sun.com/developer/onlineTraining/newBeans/
rdesai: I have a question about building a Bean which works like a data-source Bean.
SPK-rohaly: Go ahead, I'll see if I can help!
rdesai: I am fairly new with Beans stuff. Basically,
we have this object, that collects data from the Web and saves it in a structured format. I would like to build a Bean that will wrap this object and act as a data source, so that another widget--a list box or a text box--can connect to it to get some source in ActiveX, but in Beans. By the way, I read briefly about this InfoBus from Lotus, but that is still in draft stage.
SPK-rohaly: The first thing you should do is decide how the Bean will interact with other Beans. Beans have events, properties, and methods (stop me if you know this :) It sounds like you want to define some methods that other Beans can use to retrieve the data from your Bean. Also, you probably want to have your Bean generate events when it has new data. Then, of course you need a way to have your Bean initiate the fetch of new data, so it might be a listener for other events (that way you can tie a button to your Bean to initiate the fetch).
InfoBus, like you said, is still in draft stage--don't expect to see it soon. It defines a far more elaborate scheme for passing data into and out of Beans. I don't think your problem requires anything more than the basic Beans capabilities.
Once you have decided on how the outside world will interact with your Bean via its events and methods, all you need to do is write a class that implements your Bean. Possibly you need to write your own event type as well.
rdesai: I see. My Bean doesn't, and shouldn't, know anything about the other Beans. So, what you're saying is that I would have to define an event in my Bean that other Beans can connect to.
SPK-rohaly: Exactly. You can define your own event type (a subclass of java.util.EventObject) for your specific events. But you may be able to use one of the standard event types, so this isn't always necessary.
rdesai: Finally, are all the AWT components now defined as a Bean, so that they can be dropped in an app builder and be connected?
SPK-rohaly: Yes, all AWT components (and all JFC/Swing components) are Beans, so they may be used directly by an IDE (Integrated Development Environment). There are some IDE-specific issues, such as the BeanBox requires a component in a JAR file, but this is a packaging question.
And by the way, you can consider any Java class to be a Bean. It may not be a good Bean, but it will be a Bean nonetheless.
This is because there is nothing special you have to do to make a class a Bean. Meaning, you don't have to subclass anything, you don't have to provide a special interface definition, etc. However, in order to make a useful Bean, there are some things you should do, and take into account.
rdesai: Yes, I found that out when I was doing some introspection on my Java objects. I can take all my classes and make a .jar file, and then they are Beans. Do Beans have to be visual components? I assume not. But, most of the stuff I have seen and read indicates that they have a visual part to them.
SPK-rohaly: And that's exactly what an App builder does when you insert a Bean--it uses introspection to determine what the Bean's properties, events, and methods are. Beans can be visual or nonvisual. JavaSoft's definition that "a JavaBean is a reusable software component that can be manipulated visually in a builder tool" sometimes confuses people into thinking that the Bean itself must be visual, but that is not the case.
ldgpangeo: Are there compatibility issues between Sun's JDK and the BeanBox of the Beans Development Kit (BDK)?
SPK-rohaly: The BeanBox is written using Sun's JDK. The BeanBox is supposed to just be an example application builder, in the same way that the appletviewer is a minimal (very minimal) web browser. So, there are no compatibility problems between the JDK and the BDK.
rdesai: Do JavaBeans support the licensing idea ? We would like to deliver a Bean, but I want it to have some mechanism that will alllow/disallow capabilities. If the users have a developer license, they can drop my Bean in the AppDev environment otherwise they cannot.
SPK-rohaly: If you want to have some sort of license control within your Bean, you have to write that yourself. There are no explicit provisions in the API for licensing schemes. It would be fairly straightforward to do this yourself.
ldgpangeo: I've been experimenting with Beans by adding features to the veto Bean in the sample BeanBox. To avoid stomping on the original veto Bean, I named mine "nuvoter." It compiles fine in JDK, and when I move it over to BDK as a JAR the BeanBox has no trouble finding it.
When I then try to link it in the manner analogous to the original voter, it complains that it can't find the class links.
SPK-rohaly: You mean when you try to connect an event to your Bean, the BeanBox complains? Do you have the exact error message?
ldgpangeo: The message shows up in the run.bat file in Windows. The error message is "Class tmp.sun.Beanbox.Nuvoter not found in type declaration."
The source for the error is the \tmp\sun\Beanbox\__Hookup_144e338.java
SPK-rohaly: The suggestion is to never have a direct reference to another Bean--you should be connecting them through adapter classes. The BeanBox does this for you. So when your app is reconstructed, your Bean is responsible only for reconstructing its own serialized state, while the container (BeanBox) is responsible for reconstructing the interconnections.
If you desire to build a Bean that is composed of sub-Beans, then yes, you must bundle up all the parts of the Bean together when you deliver it.
The /tmp/sun/Beanbox/__Hookup_144e338.java file is an adapter class that is dynamically built by the BeanBox to interface the two Beans you are wiring together.
Your error message is coming when the BeanBox tries to compile this adapter class--somehow it can't find the .class files for your Nuvoter class.
If you look at the source code for the Hookup class, you will see an import statement like: import sunw.demo.Nuvoter; which is where the BeanBox is looking for your .class.
Perhaps your classpath is wrong?
Jon: Is there an easy way to view the System.out.println() in a Windows application? I have a GUI up but I can't seem to get any response from the menus
SPK-rohaly: Can you be more specific? If you start your application from the command prompt (on a PC), then System.out is directed to your dos window. If you are calling System.out in an applet within a browser, System.out goes to different places (depending on the browser).
As for the second question, again you need to be a little more specific. To have your menus do something, you have to define a listener class which handles the events generated by selecting a MenuItem.
Well, it's time to end the session. Thanks for coming, I hope I was able to answer your questions. Watch the schedule for more Training Office Hours sessions, to get answers to your questions about the JavaBeans tutorial.