Edward Diener No Spam wrote: > [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.
Why not propose something. That is the easiest way to get things moving. Chaz. -- http://mail.python.org/mailman/listinfo/python-list
