Introduction

Currently,the major goal of the component model is to support the development of a visual gui building tool where simple and compound components, both built in and third party, can be layed out in a panel and wired together using events, attributes and methods to create a non-trivial application.

Here's a quote I found in an article discussing the UML and how it defines components:

"component: A physical, replaceable part of a system that packages implementation and provides the realization of a set of interfaces. A component represents a physical piece of implementation of a system, including software code (source, binary or executable) or equivalents such as scripts or command files [9]."

I'm just learning about components and have a friend thats an expert in this area and is advising me and trying to steer me in the right direction. I've been thinking of PythonCard Widgets ( simple and compound ) as components, and that's really not the case. It's possible for a Widget to be a component, but only if it fulfills the responsibilities of some component model. I'm still reading up on what a component model really is.

The following is the state of my own personal take on components.

General statements about component models:

This sounds just like a class, so I know I'm missing something here...

Specific statements about a possible PythonCard component model:

Maybe leveraging Python as we have in the current resource format is a better option. Unless we're leveraging some component model that's already out there that requires XML then we're just creating a lot of extra work by going with XML.

PythonCardComponentFramework (last edited 2008-03-11 10:50:22 by localhost)

NOTE: To edit pages in this wiki you must be a member of the TrustedEditorsGroup.