On Nov 17, 2006, at 4:46 PM, Paul McNett wrote:
>> sure I see why you are doing 'from' and not just 'import.'
>> wouldn't it be
>> better to do:
>>
>> import FrmBase
>> class FrmEvents(FrmBase.FrmBase):
>>
>> So that there isn't an extra.. um.. something ?
>
> It is a style issue, completely subjective. When importing from
> modules
> to do subclasses, I like to import just the class I want to
> instantiate
> or subclass. Hence, from x import Y.
The only reason not to import specific classes is if you may have
more than one with a given name in the namespace. "from foo import
bar" brings 'bar' into the current namespace, while "import foo"
leaves 'bar' in the foo namespace. So, if you really think that there
may be another object in the namespace named 'FrmBase', you shouldn't
use the 'from...' format. Otherwise, it makes no difference, except
to make the code that uses the imported class a bit cleaner.
>> 3. self.super() - I thought the x_pre()/x()/x_post() pattern kept
>> you from
>> having to run the code in the super class because there was none?
>
> What if you put some stuff in the FrmBase method? You'd want that to
> fire, no?
Exactly. There is no code in the *framework* for those methods. But
you have two levels of sub-framework classes, and it sure doesn't
hurt to add that call. Technically, though, the super() call in
FrmBase.initProperties() is not needed, since initProperties() is
empty at the framework level. Again, though, it doesn't hurt, and is
more of a "belt-and-suspenders" design.
>> 4. self.NameBase = "frmEvents", self.Caption = "Events"...
>> shouldn't these
>> things be in an xml file?
>
> If you are into that sort of thing, this is basically what the
> fieldspecs option does. Check the "use fieldspecs" checkbox in the
> wizard to see the difference in the generated code.
No, please don't do that. The fieldspecs design is dead and not
supported. It is also very different than the *supported* XML design
for classes, which is the .cdxml format used by the Class Designer.
The plan in the future is to give an option to generate code, as is
currently done, or to generate files compatible with the Class
Designer. This way you can take the generated files and either edit
them in a text editor, if that's your preference, or in the Class
Designer/IDE, if you prefer that way of working.
>> 5. afterInit(self) is just one big constant wrapped around
>> "Events", right? so
>> why isn't the code in an abstract class that reads "Events" from
>> an attribute ?
>
> afterInit() is a method that gets called from the dPemMixin superclass
> after most of the initialization phase has been completed. I don't
> understand what you mean about it being "one big constant".
I don't understand the question, either. It's just a hook that is
called after the object is instantiated.
-- Ed Leafe
-- http://leafe.com
-- http://dabodev.com
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-dev
