Re: [Pythoncard-users] components framework

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
>