Python component model

[Chaz Ginger]

Edward Diener No Spam wrote:
> skip at pobox.com 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.