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?
or, why does it need that parameter?
>
> ... 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.
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().
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.
>
> 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?
>> there are a few reasons I think this is a good thing.
>>
>> 1. less code = less bugs. less code for me to write, less dabo code that
>> has to
>> work. I already burned an hour or so trying to figure out why my exe
>> didn't
>> work: the foo-code.py file didn't get copied, and the resulting app didn't
>> error
>> - I hit the button, and nothing happened. I can see how that is my fault
>> and
>> not a bug in dabo, but it is an example of one more thing to deal with.
>
> Yeah, I get burned with Python's weakref and dynamic magic too.
>
>
>> 2. cdxml2objDemo1-code.py is not self documenting. in my real code, I had
>> all
>> of 2 buttons, and at one point I mixed up which block of code was connected
>> to
>> witch button, so the debugging code I added confused me even more than the
>> bug.
>>
>> 3. one less thing to 'learn'. I am not confidant in my understanding of how
>> the
>> cdxml2objDemo1-code.py code gets connected to the UI controls. given that I
>> don't see much point to it, I don't see much point in taking the time to
>> learn
>> about it.
>>
>> 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.
>
>
>> 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.
>
>> 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 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 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.
>
> 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 :)
Carl K
_______________________________________________
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]
