Brett Ryan wrote:
> @Weiqi
>
> Do you like using Introspector? ;) Okay it might be a tongue in cheek
> question, but I'd still much prefer being able to do
> foo.getDeclaredProperties() and have a PropertyDescriptor array
> returned without the penalty of the Introspector having to go and
> discover them.
>
Performance of discovery is perhaps grounds for improvement. I can't
say -- if it is, then that can be fixed without changing the API.
The difference between
Introspector.getBeanInfo( Foo.class ).getPropertyDescriptors();
and
Foo.class.getBeanInfo().getPropertyDescriptors();
and
foo.getBeanInfo().getPropertyDescriptors();
is immaterial in my book.
Actually I'm rather glad it is /not/ the last of these.
java.lang.Object clutter up the method namespace enough without
something like this that could be better provided via a method on
java.lang.Class or via a separate factory class ala Introspector.
I won't say Introspector is perfect, but it works, does better than ad
hoc scraps of code like that you attached, and has been built into the
core Java libraries for many years.
--
Jess Holle
> On Wed, Nov 5, 2008 at 4:26 AM, Weiqi Gao <[EMAIL PROTECTED]> wrote:
>
>> Brett Ryan wrote:
>>
>>> But it's not baked into swing and other areas where a component model
>>> is needed, there maybe API's out there, but they aren't something I
>>> can discover. If I'm given a component from some component author who
>>> has quite simply developed some swing control, how do I place that
>>> control on a designer and be able to expose the properties of that
>>> component? Exposing events aren't as bad although not as easy as if we
>>> had true events.
>>>
>>> In the end we do something like the attached example I posted a few
>>> posts ago that iterates over the classes declared methods. Even still,
>>> I've just realised my example doesn't take the Boolean `is' into
>>> account.
>>>
>>> http://bean-properties.dev.java.net may be one solution, but whatever
>>> the solution is the actual components need to be unified to support
>>> property discovery.
>>>
>>> If you do have a way to unify getters/setters into a property without
>>> having to try and discover them I'd be interested to see.
>>>
>> The call
>>
>> Introspector.getBeanInfo(Foo.class).getPropertyDescriptors()
>>
>> will give you all the properties on the class Foo, their name, type,
>> getter, setter, bound-ness, constrained-ness, PropertyEditor, etc.
>>
>> And according to it, your earlier example
>>
>> class Bar {
>> public String getFoo() { return ""; }
>> public void setFoo(int val) {}
>> }
>>
>> has a read only property named "foo" of type String.
>>
>> The JavaBeans spec was written when AWT was still being hyped heavily,
>> and Java people were dreaming of a drag-and-drop type of GUI painting
>> paradigm. Anyone remember Bongo? I'm sure it would qualify as a Java
>> app of the week had the JavaPosse been on the air then.
>>
>> Java did not dominate in GUI development. Looking back, that's when a
>> nice developer box have 16MB, maybe 32MB RAM, and production servers
>> have 64MB RAM. My VB5 developer colleagues were laughing their heads
>> off when I downloaded Swing 0.3 (or 0.4) and the SwingSet demo started
>> up in 20 minutes!
>>
>> --
>> Weiqi Gao
>> [EMAIL PROTECTED]
>> http://www.weiqigao.com/blog/
>>
>>
>
> >
>
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---
