On Dec 10, 2006, at 10:38 PM, Paul McNett wrote:
>> 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...
At the very base, no it isn't terribly complicated, but when you get
to composite classes, it does get hairy. For a basic pageframe we'd
need dScrollPanel -> iScrollPanel -> dPage -> iPage; then for each of
the paged controls we'd need a d-version that uses iPage, followed by
an i-version. Classes like dDateTextbox would have to inherit from
iTextBox, not dTextBox, as well as every one of our dialog
subclasses. I can just imagine the headaches involved in re-writing
the datanav/AppWizard stuff to properly use these intermediate levels!
> This assumes that they'd want to modify *Dabo*, and not their own
> subclasses.
No, not really, although that's part of it. It's more like "If I
wrote this framework, I'd prefer if class X behaved this way". So you
modify the i-layer, and from that point on, all your apps have your
preferred behavior. It can either be replacing an existing Dabo
behavior, or adding something that is domain-specific.
> I don't think Carl was talking about us making this change in Dabo,
> but
> perhaps a downstream framework.
No, this really has to be done at the framework level.
>> Now he can use his CarlTextBox everywhere, and it will behave
>> exactly like a dTextBox, except when it comes to the foo() method.
>>
>
> Exactly.
>
> 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.
That's precisely why this design was used.
> 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.
VFP doesn't support multiple inheritance, and thus the mixin
solution is not available. You can sort of fake it with one of the
façade pattern implementations, but it's weak.
Having written the Class Designer, I feel certain that an i-layer is
completely unnecessary. Every one of the controls used on the design
surface is a native Dabo control, but with a couple of mixin classes
added to give them the behaviors needed in the Designer instead of
the normal runtime behaviors. In all my years of working with
Codebook and the i-layer, I've never seen an i-layer customization
that even came close to that level of modification.
> I always found VFP frameworks to be messy which is why I avoided them
> (coding my own messy framework instead). :)
Well, that's the situation we have WRT wxPython: people are creating
their own messy implementations instead of using a well-thought-out
framework. They are constantly re-inventing the wheel because they
look at someone else's wheel, don't immediately understand it, and
decide that they can do it better.
-- Ed Leafe
-- http://leafe.com
-- http://dabodev.com
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users
