On Sep 30, 2007, at 11:10 AM, johnf wrote:

> Larry's solution provides several benefits to the performance of  
> the form.
> For example changing from lbs to kilos requires no interaction with  
> the back
> end (Postgres in this case) and changes appear in an instant.

        Non-issue. Nothing I have suggested requires this, and it is counter- 
productive to keep repeating this as an item for discussion.

> The code is self contained.

        IMO, this is a serious drawback. Should there be any other place in  
the app that requires similar formatting, you have to re-create the  
code again. The whole point of consolidating formatting logic in a  
central place is to avoid this sort of duplication.

> As reported in the past, Larry's form is not as responsive
> as it should be – so any performance increase is welcomed.

        A call to a method is just as fast when that method is doing the  
same thing. Calling a method in the table is no faster than calling  
the exact same method in the bizobj.

> For example clicking on a check box within a Dabo grid does not  
> respond instantly but
> takes a least a half a second to display (on Linux).

        That sounds like a Gtk issue. How does subclassing the datatable  
improve this?

> However, there are a couple of issues that were raised immediately  
> in my mind.
> When I was helping Larry I kept asking  “why were we subclassing
> dGridDataTable”  it just sounded wrong.  Why not just use the SQL  
> interface -
> I asked.

        Why not use the alternatives I proposed? Why limit yourself to  
considering only these two options?

> The second was dGridDataTable did not know about “self.Form”
> another clue something might be wrong.

        Again, dGridDataTable is a wxPython-specific implementation detail,  
and should not be used unless a) you want to always use wxPython and  
b) you know what you're doing.

> But as I said in a earlier email
> that I could not find a simple solution to the problem and Larry's  
> solution
> was providing immediate benefits.

        I must say it seems frustrating when I've offered several possible  
solutions that were never tried, even after I explained your  
misconceptions about what I was proposing.

> So after some thought I've come to the conclusion there needs to be  
> some sort
> of Dabo interface that allows interaction with the grid fields  
> beyond what is
> currently available.   I could have missed something within Dabo  
> that solves
> the issue.  So if others have a better solution I (and I'm sure  
> Larry too)
> would like hear it.

        See above (and above, and above...)

-- Ed Leafe
-- http://leafe.com
-- http://dabodev.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]

Reply via email to