[EMAIL PROTECTED] wrote: > Edward> The definition of a component model I use below is a class which > Edward> allows properties, methods, and events in a structured way which > Edward> can be recognized, usually through some form of introspection > Edward> outside of that class. This structured way allows visual tools > Edward> to host components, and allows programmers to build applications > Edward> and libraries visually in a RAD environment. > > ... > Edward> I believe that Python should have a common components model for > Edward> all RAD development environments, as that would allow the Python > Edward> programmer to create a set of classes representing components > Edward> which would work in any environment. > > Having never used java or .NET I'm not sure what you're looking for. Does > Python's current introspection not work? Is it someone too unstructured > (whatever "structured" means)? Can you give a simple example?
In the typical RAD development environment, a particular component model allows one to drop components, which are classes corresponding to a particular inner representation which tells the development environment what are the "properties" and "events" of that component, and subsequently set "properties" for that component and add handlers for its "events" visually. Subsequently When the components are instantiated at run-time, the particular "properties" are automagically set and the particular "events" are automagically tied to event handlers in other classes ( usually a window, or form, although it can be in any other class which can handle events ). How this "automagically" is done depends on the visual development environment. I find it very neat that I, the end-user of the component, does not have to write the boiler-plate code to set "properties" and hook up "events" and can do this visually. I realize that others may find this unimportant. But in a visual environment where not only non-viusual components are involved, but also visual GUI components are, this also allows the visual look of a particular window ( form or screen if you like ) to be composed automatically. At the same time hooking non-visual components automagically at design time so that they are connected at run-time to event handlers is also very nice. In order to make such a system work, the visual RAD environment needs to know what in a class makes it a component, and what in that components specifies the "properties" and "events" for which it will automagically setup the correct "code" which works at run-time. Without a component model to tell it these things, it can not work to produce the boiler-plate code necessary to set "properties" and hook event handlers to an event. In JavaBeans, for Java, and the System.ComponentModel namespace, as well as properties, delegates, and events in .Net, there exists a common component model which defines, in these environments, what a components is so that the visual RAD development can do its magic. I realize that many Python programmers don't see the necessity for having a RAD visual devlopment environment doing for them what they can do by hand in their Python code, particularly in the constructor to classes. But there are people who have used such a RAD model, particularly when setting up a GUI application or Web application, who appreciate the ease of use of such a RAD visual environment, especially in the area of dropping visual controls on a window and having that window appear at run-time with the particular look which they have visually setup at design time. But even beyond the more common visual setup of a window or web page, a visual RAD environment allows the end-user programmer to visually create boiler-plate code for setting the "properties" and "events" of non-visual classes, which make up the greater part of the internal logic of any given program. More importantly a common component model, which works in any language's visual RAD environment, enables the development and re-use of components which are as easily used as dropping that component from a component palette onto a visual container, usually a representation of a run-time window, and setting it's "properties" and/or "events". The visual manipulation of components does not preclude making manipulations at run-time through code also if necessary, and all visual environements allow the setting of "properties" and "events" at run-time also in the usual way. If one has used Borland's Delphi or C++ Builder IDEs, or Sun's NetBeans or IBM's Eclipse for Java, or Microsoft's Visual Studio for .Net, one knows what I mean as far as a visual RAD environment. All of these are made possible by a common component model which different development environments can use. There's nothing wrong with Python's introspection. In fact Python's facilities in this area and its support for metadata are stronger than any of these other languages ! However there is no common component model which specifies that X is a "property" or Y is an "event" of a Python class which can be visually manipulated at design-time and automagically set at run-time, so that any given Python RAD visual environment will treat a Python class, specified as a component, in exactly the same way. Also in these other languages, a component is different from a class in that a component is recognized in a particular way, often so that the component can interact if necessary with its container and/or visual site. OK, I have proselytized enough <g>. Python is a great language and I truly love it and its flexibility and ease of programming use. If there is no impetus to create a component model for re-usable components for visual RAD environments in Python, that's fine with me. But I thought someone from the Python development community, given the use of visual RAD environments for other languages as mentioned above, to create GUI and large-scale applications, would have considered it. -- http://mail.python.org/mailman/listinfo/python-list
