Carl Karsten wrote:
> Paul McNett wrote:
>> Carl Karsten wrote:
>>> Paul McNett wrote:
>>>> Carl Karsten wrote:
>>>>>> Where are these files again? Please don't point me to the list archives,
>>>>>> as I can't easily copy/paste code from that webpage.
>>>>> Oh yeah, that whole html eats whitespace thing...
>>>>>
>>>>> hnmm, looks like I botched the file name too. - was called bd1, renamed
>>>>> the
>>>>> files to cdxml2objDemo1 but didn't change dabo.ui.createForm()
>>>>>
>>>>> http://dev.personnelware.com/carl/temp/May31/a/cdxml2objDemo1.tgz
>>>> Ok, your code runs, and when I click "swap" it swaps. What's the problem?
>>>>
>>> I am trying to replace this code in this file:
>>>
>>> # cdxml2objDemo1-code.py
>>> ## *!* ## Dabo Code ID: dButton-dForm
>>> def onHit(self, evt):
>>> self.Form.myObj1.swap()
>>> self.Form.update()
>>>
>>> With something in the cdxml file that connects the button to myObj1.swap()
>>> in a
>>> similar way that the text box's are connected to the attributes. (once
>>> that
>>> happens, the displaced .update() can be dealt wtih.)
>> Well, it appears that Ed hasn't yet added the ability to put a
>> OnHit="self.Form.myObj1.swap" in the attributes for the button, but
>> that's how you would do it if it were supported. You'd also have to add
>> an evt arg to your swap function:
>>
>> def swap(self, evt=None):
>
>
> um, if it hasn't been implemented, then how do you know it would need the
> parameter?
Because that's how event binding works - the callback takes an argument
that contains the event object. This *has been* implemented in Dabo for
years now. What hasn't been implemented in cdxml is the ability to
specify the binding in the constructor. Here, in raw-dabo:
import dabo
dabo.ui.loadUI("wx")
def onButtonHit(evt):
print "hit!", evt.EventObject
app = dabo.App()
app.setup()
but = dabo.ui.dButton(app.MainForm, OnHit=onButtonHit, Caption="!")
app.start()
> or, why does it need that parameter?
Because that's how event binding works, the callback function takes an
event argument.
>> ... and yes, you do need to explicitly call update(): how else do you
>> expect Dabo to know that your object's attribute values have changed?
>
> Few things come to mind:
>
> Given that most button clicks cause something to happen that requires the
> form
> to be updated, build it into the button. If that causes a problem, add an
> switch to turn it off.
You are saying that every time any button on the form gets clicked, call
but.Form.update()?
> Create a class that is specifically for storing values that might be
> displayed
> using Dabo UI objects. When the Dabo UI object is bound to the 'value
> object',
> it registers itself. Now the value object has a reference to all the UI
> objects
> that are bound to it. When the value object's value is updated, it calls the
> .update() of the UI objects bound to it. This may sound like a bit of
> overhead
> that will slow things down, but I bet it is faster than calling .update().
FWIW, there is just such a device already: binding controls to a
dBizobj, and registering the bizobj with the dForm: whenever the bizobj
field value changes, the form calls update() automatically.
> I am somewhat surprised that the wx controls don't do this automatically, but
> I
> have 0.0 idea what wx controls can/can't do.
You have to do programming to specify what the wx controls
should/shouldn't do. You say that a wx.Button should call
dabo.ui.dForm.update(), when wx is completely unaware of the existence
of Dabo?
>> Until the OnHit works within cdxml, you can put the following at the
>> bottom of your main .py file:
>>
>> if __name__ == "__main__":
>>
>> app = dabo.dApp(MainFormClass=None)
>> app.setup()
>> frm = dabo.ui.createForm('cdxml2objDemo1.cdxml')
>> frm.myObj1=myClass()
>> ## - new line below
>> frm.but.bindEvent(dabo.dEvents.Hit, frm.myObj1.swap)
>> ## - new line above
>> frm.show()
>> app.start()
>>
>> ...and then get rid of the -code.py file.
>>
>
> Traceback (most recent call last):
> File "cdxml2objDemo1.py", line 31, in ?
> frm.but.bindEvent(dabo.dEvents.Hit, frm.myObj1.swap)
> AttributeError: 'dForm_276318141' object has no attribute 'but'
>
> <dButton sizerInfo="{'BorderSides': ['All'], 'Proportion': 0, 'HAlign':
> 'Center', 'VAlign': 'Middle', 'Border': 0, 'Expand': False}"
> code-ID="dButton-dForm" designerClass="controlMix" Caption="Swap" />
>
> Where did the 'but' in frm.but.bindEvent come from?
Sorry, forgot to tell you to add RegID="but" in the dButton attributes
in the xml.
>>> 4. To me it is poor style to have code in the UI, and I thought Ed claimed
>>> the
>>> x-code.py file was just for the convince of the developer that wanted to
>>> edit
>>> code using the Dabo CD.
>> I don't see how you'll get rid of all UI code. I have a ton of UI code
>> and don't feel badly about it at all.
>
> I think we need to define what this UI code is I want to get rid of. I see a
> typical 3-tier framework app having 6 places code can live: each of the 3
> tiers
> will have framework code and 'app developer code.' For the UI tier, if the
> app's UI is not doing anything that the Framework UI code can't handle, then
> the
> closest thing to code will be config data describing how to setup the
> controls
> (exactly what is in the .cdxml)
>
> If the app needs some loopy UI gizmo like "increase the font every time the
> mouse passes over it" then I need to write some UI code.
Most UI code is layout code, yes. But also event handlers for acting
when the user clicks a button or something.
>>> Assuming this is correct:
>>> >> Just add that line to the object's afterInit() method.
>>> (which it isn't - object, [event], and .myMethod need to be replaced with
>>> the
>>> right names, and my object doesn't have an afterInit() method. but
>>> assuming it
>>> is correct anyway...)
>> That's where you edit it from within the -code.py file. You add the
>> afterInit() method there.
>>
>
> huh? I can't even guess what you are talking about. please elaborate.
Open up your -code.py file, and after the "def onHit.." block, add:
def afterInit(self):
print "afterInit", self
Now run the main .py file. You should see:
afterInit <dButton_9370141723 (baseclass dabo.ui.dButton)>
Now put whatever code Ed wanted you to put there in that method. It gets
called after the button's init cycle is complete.
>>> It seems awkward to have to have the BO layer attach itself to the UI
>>> objects,
>>> especially when some of the UI object attach themselves to the BO object
>>> (like
>>> the text box.) Not to mention that means you can't use that BO object
>>> without
>>> the UI, unless you write some conditional code, which seems beyond awkward.
>> I don't understand. How does the BO layer "attach itself" to the UI
>> objects? dBizobj isn't even aware that the UI layer exists.
>
> I was assuming I had to add that line to my BO class. I don't know what else
> "the object's afterInit() method" would refer to.
I interpreted it to be the button, but whatever, afterInit() is a hook
method of all Dabo objects. It is in fact one of the most commonly-used
hook methods, and I'm surprised you didn't know about it yet.
> I see you added it to the app's 'main' which is 'better' but still not the
> "Don't Repeat Yourself" mentality that I would expect from a framework.
> Actually nothing is being repeated... but it seems there is an extra step.
> hmm,
> maybe it is just the 2 places to set things up: in the .cdxml for text boxes,
> and app's main for the button. bah, this is just a side effect of the
> workaround to an unconfirmed missing feature. This paragraph may not have
> anything to do with reality :)
I think maybe you should take cdxml out of the picture for a while. Get
comfy with raw-dabo. You'll have a better understanding and appreciation
for what cdxml brings to the table. I think you had your code the best
with how you originally posted it earlier today. The ui code was in the
ui layer.
>> I use
>> dBizobj without a UI regularly.
>
> You also code your UI by hand, which seems to have more features than what
> can
> be currently be done with .cdxml.
The cdxml wraps Dabo, not the other way around, so I think this will
always be the case.
>> Understand, I haven't played much with the cdxml-way of doing things, so
>> my answers may not be well-informed enough.
>
> there's the problem... you are missing out on its potential goodness that
> hasn't
> been coded yet because you don't need it :)
Thinking about it, I think I misspoke about OnHit not being implemented
yet in cdxml. This is a constructor argument, and the xml doesn't define
what goes to the constructor, but what the properties are to be set to.
So... this feature is either already implemented in cdxml and I'm not
aware of it, or it will not be implemented in cdxml because there are
already other ways to do it (doesn't apply).
--
pkm ~ http://paulmcnett.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/dabo-users/[EMAIL PROTECTED]
