pythoncard-users

[Pythoncard-users] components framework

[Kevin A. <al...@se...>]

Components are another big issue that was brought up in the app framework
threads on wxPython-user. Windows COM is the most widely used form of
components, but there are also other forms of components like JavaBeans.
When Rowland and I started work on the very first pieces of PythonCard back
in July a friend of ours pointed out that the only way we could create a
framework with long-lasting appeal was by supporting a component model.

There are a number of problems with trying to do components while trying to
do something that works with multiple computer languages, across multiple
operating systems, and multiple GUI toolkits, that makes a component model
an almost impossible problem to solve.

If you limit your solution space to a single language such as Python and a
single GUI toolkit such as wxPython that already works across platforms then
the problem space is limited enough that it appears to be doable, yet still
powerful.

Jeff Turner's message and code having to do with modularizing the
organization of widgets rather than spreading out the class definitions,
specs, and event bindings brought this issue back to the top of the
framework issues. Rather than just modularizing the widgets, why not go
ahead and turn them into components?

Rowland is working on a component base that will let us treat the existing
widgets as components and make it possible to build compound components and
subclass standard components in the framework. This should also address the
issue of an app having its own custom components.

ka

Re: [Pythoncard-users] components framework

[Rowland S. <ro...@we...>]

I thought about some issues with doing a component model today.  I'm
thinking ahead to the model requirements that are necessary to support
visual tools.

We need to provide metadata about the attributes and methods of any
PythonCard component, as well as packaging the spec with the class that 
it describes, as Jeff Turner suggested.  Putting each component in it's 
own module is helpful for managing the components ( drop them in a 
directory ) as well as for organization - a component's module can 
contain the component class itself as well as any support classes and 
resources.

We need to add type information to both attribute and method definitions 
for visual tool support:

For attributes:

     name, type

For methods:

     name, # args, <arg-name, arg-type>, <return-type>


For example, right now we have the following in Button's spec.

     'label' : { 'presence' : 'mandatory' }

This would become something like

     'label' : { 'type' : 'string', 'presence' : 'mandatory' }

We then add a new section called 'methods'.  Each method entry contains
the name of the method, followed by an ordered list of args.  each arg
specifies the arguments name and type. A 'returns' element specifies the
return type, where None is like void in Java/C.

'SetLabel' : {
     'args' : [ { 'name' : 'label', 'type' : 'string' } ],
     'returns' : None
}

Also, we might want to think about using XML as the spec format.  Kevin 
mentioned supporting the wxWindows XML format.  I don't know if we could 
support it directly, but we could provide a translator that converted a 
wxWindows spec to a PythonCard spec.

XML is obviously more verbose, but at least it's self-describing, and 
that can be a plus.

I have an alternative framework that i'm using to test component 
registration, as well as a component model for PythonCard.  Below is an 
example for a Button component that extends wxPython and is self contained.

Button inherits component behavior from widget.Widget ( which extends 
component.Component, not shown ), and extends a wxPython Button.

A single event is defined, 'mouseClick'.

The component has a single attribute, 'label', of type 'string'.

A new class attribute, 'methods', has been added to define a component's 
public interface.

each method is described by name, argument names and types, and return type.

It's not shown below, but it might also be helpful to explicitly define 
whether a method is a getter/setter for a particular attribute.  This 
could be inferred from the method name, but might not work in all cases. 
  This would be useful for auto-magically binding dot notation for 
attributes.


----------
from wxPython.wx import *

import widget

wxCLIP_SIBLINGS = 0x20000000

class Button( widget.Widget, wxButton ) :
     """
     A simple push-button with a label.
     """

     events = [ 'mouseClick' ]

     attributes = {
         'label' : { 'type' : 'string', 'presence' : 'mandatory' }
     }

     methods = {

         'SetLabel' : {
             'arguments' : [ { 'name' : 'label', 'type' : 'string' } ],
             'returns' : None
         }
     }

     def __init__( self, parent, resource ) :

         widget.Widget.__init__( self, parent, resource )

         r = resource

         wxButton.__init__( self,
                            self.parent,
                            self.getId(),
                            r.label,
                            wxPoint( r.position[ 0 ], r.position[ 1 ] ),
                            wxSize( r.size[ 0 ], r.size[ 1 ] ),
                            style = wxCLIP_SIBLINGS,
                            name = r.name )
         self._bindEvents()

     def _bindEvents( self ) :
         EVT_BUTTON( self.parent, self.getId(), self._dispatchClicked )

     def _dispatchClicked( self, event ) :
         self.fireEvent( 'mouseClicked', event )
---------------



-- 
Talk to ya,
Rowland

"The whole problem with the world is
that fools and fanatics are always so
certain of themselves, and wiser people
so full of doubts."

-- Bertrand Russell,
     quoted in the book
     A Word a Day

Re: [Pythoncard-users] components framework

[Andy T. <an...@ha...>]

A component architecture in PythonCard is a killer feature.

I love components. I've played with Delphi and VB in the past and think 
that at least some of their success stems from the ability to easily 
combine standard, 3rd party and custom built components into complex 
applications.

However, a couple of points about Rowland's proposal below sprung to mind.

Do we need to know the 'type' of a component attribute? Given the 
dynamic typing of Python wouldn't it be best to leave this out of the 
specification. Having dynamically typed attributes should also 
(theoretically) aid people who subclass components. I don't have a 
strong opinion either way on this but thought I should at least mention 
it. The same goes for component arguments. With arguments, should we 
support the * and ** special cases?

XML. Hmm, I like the resource format we have at the moment. As mentioned 
previously on the list, as soon as we put resources into an XML format 
we lose the ability to edit by hand. If the only purpose is to 
interoperate with the wxWindows format then my vote is to write a parser 
and only invoke it when necessary. Having resources as native Python 
parseable data types is a good thing, I think we should keep it.

Rowland Smith wrote:

> I thought about some issues with doing a component model today.  I'm
> thinking ahead to the model requirements that are necessary to support
> visual tools.
> 
> We need to provide metadata about the attributes and methods of any
> PythonCard component, as well as packaging the spec with the class that 
> it describes, as Jeff Turner suggested.  Putting each component in it's 
> own module is helpful for managing the components ( drop them in a 
> directory ) as well as for organization - a component's module can 
> contain the component class itself as well as any support classes and 
> resources.
> 
> We need to add type information to both attribute and method definitions 
> for visual tool support:
> 
> For attributes:
> 
>     name, type
> 
> For methods:
> 
>     name, # args, <arg-name, arg-type>, <return-type>
> 
> 
> For example, right now we have the following in Button's spec.
> 
>     'label' : { 'presence' : 'mandatory' }
> 
> This would become something like
> 
>     'label' : { 'type' : 'string', 'presence' : 'mandatory' }
> 
> We then add a new section called 'methods'.  Each method entry contains
> the name of the method, followed by an ordered list of args.  each arg
> specifies the arguments name and type. A 'returns' element specifies the
> return type, where None is like void in Java/C.
> 
> 'SetLabel' : {
>     'args' : [ { 'name' : 'label', 'type' : 'string' } ],
>     'returns' : None
> }
> 
> Also, we might want to think about using XML as the spec format.  Kevin 
> mentioned supporting the wxWindows XML format.  I don't know if we could 
> support it directly, but we could provide a translator that converted a 
> wxWindows spec to a PythonCard spec.
> 
> XML is obviously more verbose, but at least it's self-describing, and 
> that can be a plus.
> 
> I have an alternative framework that i'm using to test component 
> registration, as well as a component model for PythonCard.  Below is an 
> example for a Button component that extends wxPython and is self contained.
> 
> Button inherits component behavior from widget.Widget ( which extends 
> component.Component, not shown ), and extends a wxPython Button.
> 
> A single event is defined, 'mouseClick'.
> 
> The component has a single attribute, 'label', of type 'string'.
> 
> A new class attribute, 'methods', has been added to define a component's 
> public interface.
> 
> each method is described by name, argument names and types, and return 
> type.
> 
> It's not shown below, but it might also be helpful to explicitly define 
> whether a method is a getter/setter for a particular attribute.  This 
> could be inferred from the method name, but might not work in all cases. 
>  This would be useful for auto-magically binding dot notation for 
> attributes.
> 
> 
> ----------
[snip example code]
> 
> 
> 

Regards,
Andy
-- 
-----------------------------------------------------------------------
 From the desk of Andrew J Todd esq.
"Another year older, still no wiser." - Me, on my birthday

Re: [Pythoncard-users] components framework

[Rowland S. <sn0...@ea...>]

On Monday, December 3, 2001, at 08:32 PM, Andy Todd wrote:

> A component architecture in PythonCard is a killer feature.
>
> I love components. I've played with Delphi and VB in the past and think 
> that at least some of their success stems from the ability to easily 
> combine standard, 3rd party and custom built components into complex 
> applications.
>
> However, a couple of points about Rowland's proposal below sprung to 
> mind.
>
> Do we need to know the 'type' of a component attribute? Given the 
> dynamic typing of Python wouldn't it be best to leave this out of the 
> specification. Having dynamically typed attributes should also 
> (theoretically) aid people who subclass components. I don't have a 
> strong opinion either way on this but thought I should at least mention 
> it. The same goes for component arguments. With arguments, should we 
> support the * and ** special cases?

One of the reasons for typing component attributes and methods is to 
support sophisticated visual tools that can present type-specific 
editors for attributes and method parameters.

I'm also playing with some connector classes that can be generated by a 
visual environment for wiring up events/attributes/methods between 
components, and the typing will probably come in handy here as well.

>
> XML. Hmm, I like the resource format we have at the moment. As 
> mentioned previously on the list, as soon as we put resources into an 
> XML format we lose the ability to edit by hand. If the only purpose is 
> to interoperate with the wxWindows format then my vote is to write a 
> parser and only invoke it when necessary. Having resources as native 
> Python parseable data types is a good thing, I think we should keep it

I prefer the dictionary format as well.  for the near term there's 
really no reason to go to XML.  I would prefer to work on more 
interesting stuff like components, etc. , than write XML->Python 
translators ;)


> Rowland Smith wrote:
>
>> I thought about some issues with doing a component model today.  I'm
>> thinking ahead to the model requirements that are necessary to support
>> visual tools.
>> We need to provide metadata about the attributes and methods of any
>> PythonCard component, as well as packaging the spec with the class 
>> that it describes, as Jeff Turner suggested.  Putting each component 
>> in it's own module is helpful for managing the components ( drop them 
>> in a directory ) as well as for organization - a component's module 
>> can contain the component class itself as well as any support classes 
>> and resources.
>> We need to add type information to both attribute and method 
>> definitions for visual tool support:
>> For attributes:
>>     name, type
>> For methods:
>>     name, # args, <arg-name, arg-type>, <return-type>
>> For example, right now we have the following in Button's spec.
>>     'label' : { 'presence' : 'mandatory' }
>> This would become something like
>>     'label' : { 'type' : 'string', 'presence' : 'mandatory' }
>> We then add a new section called 'methods'.  Each method entry contains
>> the name of the method, followed by an ordered list of args.  each arg
>> specifies the arguments name and type. A 'returns' element specifies 
>> the
>> return type, where None is like void in Java/C.
>> 'SetLabel' : {
>>     'args' : [ { 'name' : 'label', 'type' : 'string' } ],
>>     'returns' : None
>> }
>> Also, we might want to think about using XML as the spec format.  
>> Kevin mentioned supporting the wxWindows XML format.  I don't know if 
>> we could support it directly, but we could provide a translator that 
>> converted a wxWindows spec to a PythonCard spec.
>> XML is obviously more verbose, but at least it's self-describing, and 
>> that can be a plus.
>> I have an alternative framework that i'm using to test component 
>> registration, as well as a component model for PythonCard.  Below is 
>> an example for a Button component that extends wxPython and is self 
>> contained.
>> Button inherits component behavior from widget.Widget ( which extends 
>> component.Component, not shown ), and extends a wxPython Button.
>> A single event is defined, 'mouseClick'.
>> The component has a single attribute, 'label', of type 'string'.
>> A new class attribute, 'methods', has been added to define a 
>> component's public interface.
>> each method is described by name, argument names and types, and return 
>> type.
>> It's not shown below, but it might also be helpful to explicitly 
>> define whether a method is a getter/setter for a particular 
>> attribute.  This could be inferred from the method name, but might not 
>> work in all cases.  This would be useful for auto-magically binding 
>> dot notation for attributes.
>> ----------
> [snip example code]
>
> Regards,
> Andy
> -- 
> -----------------------------------------------------------------------
> From the desk of Andrew J Todd esq.
> "Another year older, still no wiser." - Me, on my birthday
>
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
>

RE: [Pythoncard-users] components framework

[Kevin A. <al...@se...>]

> Also, we might want to think about using XML as the spec format.  Kevin
> mentioned supporting the wxWindows XML format.  I don't know if we could
> support it directly, but we could provide a translator that converted a
> wxWindows spec to a PythonCard spec.
>
> XML is obviously more verbose, but at least it's self-describing, and
> that can be a plus.

XML may be workable, but the wxWindows XML resource format is not suitable
for representing the spec, it is designed for loading wxWindows/wxPython
layouts and menus. The source code and associated README is the only real
documentation right now.

http://cvs.wxwindows.org/cgi-bin/viewcvs.cgi/wxWindows/contrib/src/xrc/

http://cvs.wxwindows.org/cgi-bin/viewcvs.cgi/wxWindows/contrib/src/xrc/FORMA
T.txt?rev=HEAD&content-type=text/vnd.viewcvs-markup

demo.py included in wxPython includes a sample. See XML_Resource under
Window Layout.

There is no DTD for the XML resource format because a DTD apparently can't
describe all the format needs. The main benefit of using the wxWindows XML
resource format is to leverage other wxWindows layout tools such as
wxDesigner. Before we would be able to do that we will have to get more
involved so that the tools and resource format support classes other than
the base wxWindows classes. The format may also need to be enhanced to
support two-step initialization and names for non-window resource items such
as menus.

I would like to have a wxWindows/wxPython/PythonCard compatible resource
format, but a lot more work needs to be done at the wx-dev C++ level to make
this happen. We can use XML for the resource spec, but that is a separate
topic and for now I recommend using the dictionary/list format until we know
all our requirements and standardize the fields, type info, order, etc.

ka