fumanchu wrote: > > 4) Custom property and component editors: A component editor can present > > a property editor or an editor for an entire component which the visual > > design-time RAD environment can use to allow the programmer end-user of > > the component to set or get component property values. Normally a design > > time environment will present default property editors for each > > component property type, but a component can override this. > > This is the hard part. I believe Dabo has done some work in this space, > but this is where the tight coupling comes in between code and tool, a > coupling which Python has traditionally resisted.
I do think it's just about presenting component properties and their types / value ranges. I do think this can be easily achieved using decorators that might also add the right kind of token for introspection purposes to the function/method attributes. Descriptors i.e. customized binding semantics might cover one aspect of componentization but as I understood Edward he asked for uniform declarative semantics. Components in this sense are just specialized objects such as TestCase classes in the PyUnit framework. What I still do not understand is the reference to "many RAD" tools which is completely hypothetical to me. The portability of components across different GUI designers for the same underlying toolkit is a quite speculative future requirement to say the least. -- http://mail.python.org/mailman/listinfo/python-list
