Okay, so wheres the answer for compile time safety? My attached ad-hoc code was not meant to be used, it was to demonstrate what Introspector or any other inspector needs to do to discover properties. What you get back are `assumed' properties (if BeanInfo classes haven't been defined).
-Brett On Wed, Nov 5, 2008 at 4:44 AM, Jess Holle <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
