Fredrik Lundh wrote: > Edward Diener No Spam wrote: > >> There's no doubt that Python's excellent introspection mechanism allows >> an outside RAD-like tool to inspect the workings of any Python object. >> But that does not make it a component model in my original use of the >> term on this thread. A RAD tool needs to know what properties and events >> within a class can be manipulated visually, and it needs to be able to >> serialize those properties and events so that they are set at run-time >> automatically once an object is created. > > external serialization was not part of your original definition.
Well, knock me over. > > I think you have to be a *lot* more concrete here. repeatedly referring to > "some kind of hypothetical property (that isn't a property)" and "some kind > of hypothetical event (that isn't a public method)" and "some kind of hypo- > thetical RAD tool" won't get you anywhere. My OP was just to query whether a component model existed for Python, like JavaBeans for Java or .Net for C#, C++/CLI etc. After that came suggestions of what I thought such a component model was about, which I thought I answered generally. Not you want details. No doubt next will come a demand for code. OK, here is my idea of what such a component model envisages as a list of items. After this, unless I get some intelligent comments from people who might be interested in what I envision, or something very similar, I will be off to investigate it myself rather than do battle with the horde of people who will just tell me that Python, being a great language, does not need what I have suggested. 1) Component property: This is a glorified attribute with a type that can either be specified in a "static" manner, or always be discovered dynamically, or have converters back and forth between a string and the actual value represented by the component property. A component property has a getter function to retrieve the value if it is readable and a setter function to set the value if it is writable. It must be either readable or writable or both. A component property is not any Python class attribute since a component has the right to specify only certain values as manipulatable in a design-time RAD environment. 2) Component event: This is an type which encapsulates an array, or a list of callable objects with the same function signature, along with the functionality to add and remove elements from the array, as well as cycle through the array calling the callable objects as a particular event is triggered. A component event is an event source for a particular event. Component events have to be dicoverable by the Visual RAD system so that an object's appropriate event handler, an event sink, can be hooked to the component event itself, an event source, through a design time interface which propagates the connection at run-time. 3: Component serialization: A component which has its properties and events set by a visual design-time RAD environment needs to be serialized at design time and deserialized at run-time. This can be a default serialization of all component properties and events, or the component itself can participate in the serilization effort either wholly or partly. 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. 5) Custom type converters: A component should be able to specify a custom converter for any property to convert, in both directions or either direction, between the property's string value as seen by a property editor and the actual value of the component property's type. This is the general gist of those things which are needed in a visual Design-time RAD environment. -- http://mail.python.org/mailman/listinfo/python-list
