Paul McNett wrote: > Paul McNett wrote: >> Ed Leafe wrote: >>> On Jan 3, 2007, at 11:58 AM, Carl Karsten wrote: >>> >>>> Lets say I want to use my version of getFields() which I am >>>> assuming requires >>>> additional GRANTs, and so won't be rolled into the dabo classes. >>>> >>>> Where should I put it? >>> Oooh... what a straight line! Must...resist... >>> >>> Why not create a dbCarl.py file, and set your connection type to >>> 'Carl'? >> I think he's wanting to override dBizobj.getFields() with his own >> implementation. One solution to this class of problem is to use Python's >> dynamism: >> >> import dabo.biz.dBizobj as dBizobj >> def getFields_carl(self): >> print "hello carl" >> dBizobj.getFields = getFields_carl >> >> As long as that happens before you instantiate your first bizobj, it'll >> work. > > I forgot to mention that I've given up trying to have a general solution > for the backend database to provide the field structure. Indeed, I > believe getFields() is one of the older attempts at it. Instead, I > explicitly define the DataStructure in my bizobj's. It is faster as well > as explicit. See: > > http://paul.dabodev.com/doc/api/dabodoc/dabo.biz.dBizobj.dBizobj.html#Properties_DataStructure > > I've also taken to removing all the addField() calls, and replacing them > with a function called addFieldsFromDataStructure(), since all the > needed information is there. >
""" This information will try to come from a few places, in order: 1) The explicitly-set DataStructure property 2) The backend table method """ The "try this, try that" tatic bothers me, but I am not sure why. I think I would prefer a prop that governs what method should be tried. Heck, make it a list of function calls. then you can pick the ones you want and the order. But I do like the various methods, which makes me think there is room for one or two more: 1. my code and 2. a file created at design time by this function that is then read at run time (which will take care of the app user not having rights needed.) The down side to #2 is what happens if a data type changes? I was pondering how tightly coupled things should be to a data structure. I don't have a feel for how often a field datatype changes. My guess is it is limited to "we didn't make the company name field long enough - add 10." or maybe a numeric type being changed from int to float. I can't fathom changing from int to date. In other words, no changes that would effect what I call the 'dabo datatype' - which is either Python's set of maybe a subset. I am guessing is is just needed for UI formating - char takes anything, numeric takes number, dates dates... From Paul's comments, I get the feeling data type changes aren't something to accommodate. If that is the case, then I'll stop pondering and go back to making a one size fits all solution. Carl K _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-dev
