Paul McNett wrote: > Ed Leafe wrote: >> On Dec 10, 2006, at 8:13 PM, Paul McNett wrote: >> >>>> VFE's solution was the i-layer - a 1:1 (basically) set of sub- >>>> classes of the >>>> framework classes that were empty. an app was built by sub >>>> classing the i-layer >>>> classes. >>>> >>>> I am starting to code something that will subclass everything in >>>> the dabo >>>> site-package. but I can't figure out how to get a list of >>>> 'everyting'. >>> You are probably talking about all classes in dabo.ui. Take a look at >>> dabo/ui/uiwx/concordance.py. As one of its first tasks it gets all the >>> classes in dabo.ui and iterates them to do its job. You could probably >>> just copy/paste that code to do what you want. >> No, he is talking about something much more involved. I created the >> original i-layer in Codebook, which was then adopted by VFE in their >> framework. It requires that every base Dabo class be subclassed and >> stored separately from the base class, and that every composite class >> be composed of these first-level, empty subclasses rather than the >> current base classes. It is not a simple thing to do. >> >> For example, grids are composed of columns. Currently in Dabo, we >> have a dColumn class, and a dGridClass. I'm leaving our the >> dGridTable class for simplicity's sake. >
handy that VFE was derived from Codebook - less explaining. They didn't do the zig-zag of using i-layer. which made for some 'ickyness' when they built things and used their own classes. I seem to remember the discussion ending with "it is too confusing to do it 'right'" which always bothered me. The 'simple but not quite right' approach means you have to understand the wacky workarounds, which to me are more complicated than the zig-zag bouncy bouncy right way. > > >> In the i-layer design Carl is >> talking about, we'd create an empty subclass called 'iColumn', and >> our dGrid would then have to be composed of iColumns. We'd then >> subclass that to an empty iGrid class. > > So iGrid would have a ColumnClass of iColumn. Doesn't seem too > complicated... > I agree. > >> The reasoning behind this is that since the i-layer classes are >> empty, they will never change. Developers can put their personal >> customizations into their local i-layer classes, and they'd never >> have to worry that a subsequent release of the Dabo base classes >> would ever overwrite their changes. > > This assumes that they'd want to modify *Dabo*, and not their own > subclasses. > um... something wonky. They do want to modify Dabo, but the mod is done in their own subclass. > >> One consequence is that we would have to then instruct everyone to >> base their code on these empty i-level classes, since creating >> objects on the d-level classes would defeat the whole point of this >> complex class structure in the first place. right! good! instruct everyone now! :) > > I don't think Carl was talking about us making this change in Dabo, but > perhaps a downstream framework. > does "downstream framework" = "carl's personal version"? If so, then right. i think the what is and isn't Dabo is getting fuzzy. > >> Personally, while I see some benefit in this sort of design, I also >> see a lot of downside to it, too. When I created the original Dabo >> tiers, I thought of including this, but honestly, I thought it would >> be way too much for most people to grok. Codebook had already built a >> following by the time I created the i-layer; it wasn't there from Day >> One. There are 2x2=4 groups of people: those that do/don't want to override dabo framework code and those that do/don't understand the i-layer idea. 1 do, do = easy to manage changes. 2 do, don't = change the code in the dabo classes and have to merge updates. 3 don't, do = i-layer is useless. 4 don't, don't = spend a bit of time and at some point realize they don't care. So by not providing the i-layer out of the box, you are saving the group 4 some headache but making the group 1's have to be 2's. > > I don't see the need for it. But maybe I need to be educated to see the > light. Seems like an unnecessary complication. That is because you are at the top of the food chain :) > > >> Subclassing is also much easier in Python than it is in VFP; in >> fact, I think that a better and cleaner solution would be to create >> mixin classes instead. Let's say that Carl wanted a class that did >> everything that the Dabo dTextBox class did, except for its foo() >> method. In an i-layer design, he'd modify his local iTextBox class's >> foo() method; in a mixin approach the solution would be something like: >> >> class CarlTextBoxMixin(object): >> def foo(self): >> # Do my custom stuff >> >> class CarlTextBox(CarlTextBoxMixin, dabo.ui.dTextBox): >> pass >> >> Now he can use his CarlTextBox everywhere, and it will behave >> exactly like a dTextBox, except when it comes to the foo() method. > > Exactly. Do the Dabo tools make it as easy to use CarlTextBox as dabo.ui.dTextBox? > > I thought VFP frameworks did this so that people didn't need to worry > about framework updates messing up their modifications, if they modified > a few lines in the gazillion line textbox.valid, for example. Like you, > I just don't see this class of problem in Dabo, but perhaps if someone > made a specialized sub-framework it would be seen as beneficial, which > is why I answered what Carl asked for which was how to find all the dabo > ui classes. I am still sensing a disconnect between what I am looking for and what you think I am looking for, or why, or something. I want to be able to hack on the dabo framework classes and then "svn up" and not have to deal with the collisions. to some degree I will have to deal with them, but in a more passive way. "oh, some new feature was added that I am not using because I don't call the super code. maybe I should do something about that." as opposed to "crap - I don't get any of the updates to this file because of the one change I made until I merge my change with their change." Carl K _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users
