Data binding isn't working for you? We have support for this via
CustomTypeDescriptors which describe the Python objects and we have some test
cases to verify it works. Note it was broken before 1.1.1 although it's been
working in 2.0 for a little while now. For example:
import clr
clr.AddReference('System.Windows.Forms')
import System.Windows.Forms as SWF
import System
class AgeQualifier(object):
def __get__(self, instance, ctx):
if instance.Age < 13: return 'young'
if instance.Age < 20: return 'teen'
if instance.Age < 30: return 'twenties'
if instance.Age < 40: return 'thirties'
if instance.Age < 50: return 'forties'
return 'old'
SAMPLE_DATA = [('Joe', 23, 'twenties'), ('Bob', 8, 'young'), ('Thomas', 32,
'thirties'), ('Patrick', 41, 'forties'), ('Kathy', 19, 'teen'), ('Sue' , 77,
'old'),]
class Person(System.Object):
def __init__(self, name, age):
self._name = name
self._age = age
def get_name(self):
return self._name
def set_name(self, value):
self._name = value
Name = property(get_name, set_name)
def get_age(self):
return self._age
def set_age(self, value):
self._age = value
Age = property(get_age, set_age)
AgeDescription = AgeQualifier()
class Form(SWF.Form):
def __init__(self):
SWF.Form.__init__(self)
self._people = people = []
for name, age, ignored in SAMPLE_DATA:
people.append(Person(name, age))
grid = SWF.DataGridView()
grid.AutoGenerateColumns = True
grid.DataSource = people
grid.Dock = SWF.DockStyle.Fill
self.grid = grid
self.Controls.Add(grid)
form = Form()
SWF.Application.Run(form)
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pigneri, Rocco
Sent: Tuesday, February 05, 2008 9:15 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Exporting Python code as an assembly
Curt,
This is a great feature and was one of the first features that I investigated
when I first got my hands on IP.
I see an immediate need for this feature in using data binding with Windows
Forms controls. Many controls (such as DataGridView and ListView) reflect over
the properties of bound objects in order to display this data dynamically with
no programmer setup. Because IP types are dynamic, WinForms cannot find any
properties to bind and creates an "empty" object. In order to use these
features now, I must create static interfaces with the required properties in a
separate assembly and then inherit that interface whenever I bind to business
objects.
To make using these UI controls easier, it would be great if property
statements could be turned into static properties either automatically or via a
flag. It seems that IP already matches properties to the correct static
getter/setter as defined in the interfaces so this should be a reasonable
request. This staticization would remove the need for the separate static
interface.
Another situation in which this would be really helpful--although less
critical--involves situations where I want to use a static tool on an IP
assembly (for example, I want to use NUnit to test my IP classes). I say that
this is not critical as a lot of tools already have Python-specific versions
available--PyUnit is a good example.
Finally, would there be a way to simplify programmer work by providing
"standard" static creators that are turned on and off at a high level? For
example, programmers could use a "compiler" switch to turn all functions into
"void func(object, . . .)" and "object func(obj. . . )". I see this being
useful in situations such as using NUnit because all that is really needed is
the proper number of arguments and the right function name (all of which are
already known in Python). If things then work the way that I think they work,
you could then just pass the objects into the correct comparators, and if they
are the right type, then the tests will run. Otherwise, you'll get an
exception.
Hope that helps,
Rocco
________________________________
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Curt Hagenlocher
Sent: Monday, February 04, 2008 1:31 PM
To: Discussion of IronPython
Subject: [IronPython] Exporting Python code as an assembly
After a bit of spare-time hacking this weekend, I've got a "proof-of-concept"
program that takes a Python class and exports it as a (statically-defined)
assembly. It uses Pythonic function annotations to signal attributes and input
and output types to the wrapper generator. You end up with something like this
def Test(object):
@ClrAttribute(Xunit.FactAttribute)
def WorthlessTest(self):
Xunit.Assert.Equal[type(1)](1, 1)
@ClrAccepts(System.String, System.Int32)
@ClrReturns(System.Int32)
def CalculateValue(self, s, i):
return len(s) + i
The program takes this source and spits out a DLL containing the class "Test"
which implements "WorthlessTest" and "CalculateValue". The class itself
contains a reference to the actual Python object, and each of the public
functions simply delegates to the Pythonic implementation.
I'm still working on cleaning up the source a little before releasing it, but
was wondering if anyone had some feedback on the design as described so far.
What should be changed or implemented in order for this to be more useful to
you?
Thanks,
-Curt
--
Curt Hagenlocher
[EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]>
_______________________________________________
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
