On Friday 19 March 2004 01:24, Berin Loritsch wrote:
How about all that code that was designed with JavaBeans specs in mind?
What about it?
Are they not components after a fashion? At least according to Sun.
Will you be able to support that too? If so, to what level? How much busy work does a person have to do to make that JavaBean that does what I need work in the new Avalon?
How often does he have to do it? How many people have to do the wrapper, and press Publish in their IDE?
Why should we event have to worry about a wrapper?
Oh, is that not part of the re-use we are talking about?
Why not? Btw, isn't JavaBeans to constricting for your taste, all these naming conventions, semantics, meta information and what not?
If you really think that about me you have totally missed the point of everything I have said and our time is wasted. My appologies.
Heck, you know that a modern J2EE container can provide you with all the configuration points for a JDBC DataSource component? How? Well, because of the JavaBeans Spec.
You probably know more about JDBC than I do, what is a DataSource component? Does it happen to be that a DataSource component have to follow certain rules? You say JavaBeans, and might it not be that there are some stuff implied in the getXyz() names? Via BeanInfo (what is that by the way, meta perhaps?)?
The DataSource component is javax.sql.DataSource. All J2EE compatible drivers have something that implements this interface. However, directly on the implementing class is all the setters and getters for the individual component configurations. Essentially JavaBeans is a set of naming guidelines to enable reflective setting of properties. The reason for the naming conventions can then translate into something easy to tool.
Granted, the same type of thing can be done using attributes instead of naming conventions. The attributes would prove more flexible as well because they can include more information than the general "Type" that is acceptable. That would minimize the occurance of IllegalArgumentExceptions, etc. because the tool would then be able to provide a control that does not allow the user to input bad information.
However, in order to tool that, the current Avalon Meta package is woefully unequipped. Then again, I am sure there are a number of other ways to accomplish the same goal. But, as you say, it comes down to the tools that enable the user to do what they need.
There are dozens of tools around that do that. What value are we adding?
Do I have to answer it?
Eventually. To users, not me.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
