I'm answering your questions before I review your code.  
On Tuesday, April 19, 2011 08:31:57 am Rasmus Schøler Sørensen wrote:
> Hi John,
> 
> I do not experience any issues with my dropdown lists in linux/ubuntu. I do
> however have a few questings, if that's ok. (I am still very new, so my
> questions may seem trivial, but here goes):

The problem started to occur after adding the 7th or 8th dropdown and about 
the time I started having need to link them.  Keep mind that I see no 
performance issues on windows.
> 
> 1. I can see that you run the "updateChoices" methods (penalcodeChoices and
> courtChoices) on every update. Is this really the way to do it? The PyCon
> examples uses a "_needChoiceUpdate" attribute and only updates the choices
> when it is really needed. I can also see that you invoke self.removeAll()
> in self.update() - again, I'm not sure that is needed (but I could be
> mistaken!).

I have been trying to come up with a better way to deal with dynamic data 
changes in a dropdown list.  The changes can not be just filters because the 
data volume is sometimes large.  On the windows side the update methods did 
not take any noticeable time to update dropdown.   Also I put counters in the 
update methods and discovered that update method was executed only three times 
for a total of < 19 ms (data access time). 
> 
> 2. I can see that you have specified DataSource+Field for pclist. But, you
> say that the choices+keys are changed/filtered in some dynamic way. What if
> the datafield's value is not among the available keys?
yes that does occur - and has been an issue that I have not solved completely.  
But each of the dropdown values is suppose to be associated with a real key in 
a table.  The table data (keys etc.) are not suppose to be deleted.  But what 
if I have a table where the data was deleted?  

I see this issue of missing data causing an exception - a result of the way 
the framework uses dropdowns and associates table data.  What other way could 
it work (haven't review you code yet)?

BTW I add the 'NONE" and 0 values to deal with a new blank record.  But I do 
not account for the issue of table value not matching the values available in 
the dropdown in some universal way.  To be honest in a real world app I have 
it has not presented it's self as a problem.  I guess it would still best if I 
catch the exception and do something.  
> 
> I follow you very well regarding your considerations about list-controls,
> especially when they both have to be updated dynamically and (optionally)
> associated with a DataSource+Field. I have tried to create a mixin class
> for UI list widgets with completely generic logic for this kind of stuff
> keys+choices logic. I just set the datafield and -source (or bizobj) from
> which it should get the keys+choices, and then most is taken care of in
> the mixin class. It can also filter the values according to values from
> other fields in the keys+choices source, and some other automatic logic.
> (source:
> https://bitbucket.org/rasmusscholer/oligomanager/src/91e226ec9cf5/oligomana
> ger/ui/ListMixin.py )
> 
> However, it was really a pain to figure out how to implement this
> correctly with lots of pittfalls along the way (it isn't completely in
> place yet!). It would be neat if someone would add this kind of
> "keys+choices" mixin class for UI list widgets to Dabo's lib. I mean, one
> that works and does things The Right Way (tm)    :-)

First let me say I don't suggest I know the right way!  But I look at the code 
and see if would help with my problem (my is one of performance).  I'll also 
check to see if it will help solve other issues I have with the dropdown.
> 
> 
> 
> Best,
> 
> Rasmus.
> 
> On 16 April 2011 20:04, John Fabiani <[email protected]> wrote:
> > Hi,
> > I have written about this issue in the past in several different forms -
> > posts.  Today I decided to give it another go at attempting to find the
> > issue
> > over this weekend.  But before I get started I thought I'd ask the list
> > for their thoughts on an insight I believe I've come to understand.
> > 
> > 
> > Every time I add a dropdown to my forms - performance drops.  The form
> > opens
> > slower and the general response to using the dropdowns is really
> > noticeable (none of this applies to windows).  Below is how I normally
> > setup my dropdowns.
> > 
> > I hand code my forms.  And in the afterInit I will setup the dropdown as
> > follows:
> > 
> > pccodechoices,pccodekeys= self.Form.penalcodeChoices()
> > 
> >        pclist=dabo.ui.dDropdownList(self, Name =
> >        'pccodeChoices',ValueMode
> > 
> > =
> > 'key', RegID = 'pccodeID', Choices = pccodechoices, Keys = pccodekeys,
> > DataSource = "public.esenroll", DataField = "fk_pccode")
> > 
> > <b>OR</b>
> > 
> > courtlist=CourtDropDown(self, ValueMode = 'key', RegID = 'courtID',
> > DataSource
> > = "public.esenroll", DataField = "fk_escourts")
> > 
> > courtlist.bindEvent(dabo.dEvents.Hit, self._courtChange)
> > 
> > Where CourtDropDown is a class
> > 
> > class CourtDropDown(dabo.ui.dDropdownList):
> >    def update(self):
> >        self.removeAll()
> >        self.Choices,self.Keys = self.Form.courtChoices()
> >        self.super()
> > 
> > The routine to set the Choices and Keys is normally as follows and is in
> > the
> > MainForm class:
> > 
> > def courtChoices(self):
> >        courtDS = self.escourts.getDataSet()
> >        availableChoices=['<None>']
> >        keyChoices=[0]
> >        
> >        for row in courtDS:
> >            availableChoices.append(row['court_name'])
> >            keyChoices.append(row['pkid'])
> >        
> >        return availableChoices,keyChoices
> > 
> > <b>OR</b>
> > 
> > def penalcodeChoices(self, pcstate = None, statechar = None):
> >        localTempCur = self.PrimaryBizobj.getTempCursor()
> >        
> >        if pcstate and statechar is None:
> >            localTempCur.execute("select state_1 from escourts where pkid 
> >            =
> > 
> > %s" % (pcstate))
> > 
> >            self.pc_stateID.Value = localTempCur.Record.state_1
> >            localTempCur.execute("Select pkid, ccode, cdescript, state_1
> > 
> > from
> > public.pc_code where state_1 = '%s'" % (localTempCur.Record.state_1))
> > 
> >        elif statechar and pcstate is None:
> >            localTempCur.execute("Select pkid, ccode, cdescript, state_1
> > 
> > from
> > public.pc_code where state_1 = '%s'" % (statechar))
> > 
> >        else:
> >            localTempCur.execute("Select pkid, ccode, cdescript, state_1
> > 
> > from
> > public.pc_code")
> > 
> >        penalDS = localTempCur.getDataSet()
> >        #penalDS = self.miscBizobj.getDataSet()
> >        availableChoices=['<None>']
> >        keyChoices=[0]
> >        
> >        for row in penalDS:
> >            pc = row['ccode'] +', ' + row['state_1']
> >            availableChoices.append(pc)
> >            keyChoices.append(row['pkid'])
> >        
> >        return availableChoices,keyChoices
> > 
> > On the windows platform I see little change in performance as I add
> > dropdowns
> > to the code.  But on Linux I see major issues with the performance of the
> > dropdowns.  They take as much as a full minute (sometimes much longer) to
> > allow selection of the choices/items.  Please do not misinterpret me -
> > the code on Linux works but very very slowly.
> > 
> > My question:
> > 
> > Reviewing my code - is there a better way of providing the choices and
> > keys for a dropdown?  Most of the dropdowns require that I change the
> > Choices, Keys
> > in some dynamic way to match the needs of the user at the time of data
> > entry.
> > Although, I do have a few static dropdowns.  I know for a fact that the
> > access
> > to the data is very fast (less than a few ms per request) and therefore
> > not the reason the dropdowns take so long to respond.  Also note that
> > the same data access occurs for the windows platform and there are no
> > performance issues.
> > 
> > Please note that I require the Choice = None and the Key = 0 due to
> > creating a
> > new record (data entry) and the dropdown control points to a None value
> > after
> > creating a new record.
> > 
> > Any thoughts would be helpful.
> > 
> > Johnf

_______________________________________________
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]

Reply via email to