On Wed, Aug 12, 2009 at 13:23, <[email protected]> wrote:
>> I agree on the control. I tend to favor #3 the most but tend to
>> decouple by passing the appropriate bizobj objects into the dialog
>> through the constructor.
>
> This sounds interesting... What's the constructor, and how does one pass
> bizobj objects through it?
It's a class constructor. Your __init__ method. You would structure
your method in this way:
def __init__(self, parent, myBizobj, *args, **kwargs):
self.myBizobj = myBizobj
super(myClassName, self).__init__(parent, args, kwargs)
Make sure you call the super method so that the proper wx
initialization can take place. On a side note, this is one of the
only instances I've found it useful to touch the __init__ method of a
Dabo framework object.
>> My thoughts on this are that my models for
>> standard things like customers and orders tend to vary very little, so
>> I can use this approach without sacrificing modularity and still take
>> advantage of Dabo's built in UI to biz layer connection properties
>> (DataSource and DataField). Validation is the only sticky part of the
>> dialog for me at this point.
>
>
> In other words, the modules change little, but since they do change, you
> still have to validate them?
Two separate thoughts. Validation in the dialog, particularly getting
it to interact with the GUI and display errors requires some code to
get working but I have subclassed that out at this point. My thoughts
on standardized models still hold.
Regards,
Nate
www.finelineautomation.com
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users
Searchable Archives: http://leafe.com/archives/search/dabo-users
This message:
http://leafe.com/archives/byMID/[email protected]
