> Much easier to do this. In your constructor, pass a reference to the
> page 1 control panel. You have your update function use that
> reference to grab the values for the constraints. Then update.
> Because your panel classes are different objects and have different
> bizobjects, updating one won't affect the others.
>
> That's one solution, and even though I don't like the coupling, it'll work.
>
Ok, dumb question coming.
I'd like to design the form as a custom class using the designer.
Can I just import the generated code file from the custom class?
I'm guessing not, because I haven't seen anything in there that ties
the code to the xml description.
So using the class designer, how do I pro grammatically instantiate
the custom panel class? Is there an import_from_xml or
instantiate_from_definition like method?
Where should the bizObj instance construction go- in the custom forms
beforeInit()?
Although it seems a bit wasteful to have a bizObj/viewPanel. Am
hoping that Ed can explain the use of _CurrentCursor & keys, but this
is definitely workable.
Thanks Nate-
Julian
> >
> > To be honest, just talking about it, I think it makes a lot more sense
> > that Page 1 becomes a dialog, triggered by the update button on the
> > viewerPanel(s).
> >
> > So the thing I'm not sure about is how to adjust the 'where
> > clauses'/filters on the bizObject connected to my test_results table,
> > and have that only cause an update of one viewerPanel, not all of
> > them.
> >
> > Ed is suggesting keys and _CurrentCursor, that I suspect sounds like
> > the right way to go, but I don't yet understand how to create
> > keys/what they are/how to use them.
> >
> > > That's all fine and dandy, but we still need a way of updating the
> > > other objects. The most elegant way of doing this in my opinion is to
> > > implement the viewPanel class as a borg DP. The shared state would be
> > > a list of viewPanels created. Each class upon instantiation will add
> > > itself to the list. On updating, a function can cycle through the
> > > list and update all of the panels.
> > >
> > If it doen't mean permanent assimilation, can you explain what you
> > mean by a borg DP? ;-)
> > Otherwise though, I think that's heading in the wrong direction to
> > what I want, but I'm not sure- what do you think?
>
> Disregard this then. Basically, the design pattern is using the code
> below to share a variables between all subjects.
>
> class Borg:
> __shared_state = {}
> def __init__(self):
> self.__dict__ = self.__shared_state
>
> Basically you have a situation where if you have 3 borg objects (a, b,
> and c), you get something like this:
>
> >>> a['testVariable'] = 42
> >>> print b['testVariable'], c['testVariable']
> 42, 42
>
> All of the behaviors and variables not in __dict__ are separate
> instances for each object. This is just an easy way for objects to
> keep track of how many others were instantiated.
>
> > Thanks!
> >
> > Julian
> >
> > _______________________________________________
> > Post Messages to: [email protected]
> > Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users
> >
>
> _______________________________________________
> Post Messages to: [email protected]
> Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users
>
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users
