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