Carl Karsten wrote: > The nightmare begins... > > So I am taking a look at what the app wiz generated. I am bummed that there > is > generic code in the 'instance layer'. like FrmEvents.py, pasted below.
Please remember that one of the main purposes of the AppWizard is to *generate code* to show people how they might write their own Dabo code. We've generated code that people can tweak, add to, or remove as they see fit. > Until I get comphy, I will start by posting here and once something passes > some > thing feel free to tell me to post it somewhere else, like the bug tracking > thing that I wasn't able to log into. See Ed's trick on logging in: click to add an issue which will present you with the login dialog. It sounds like you want to add an issue, anyway, so what the hey. > 1. A header would be nice, like the file name. where do you want me to post > that request? Let me get this straight: you want a header with the file name, when you ostensibly already know the file name because you are, after all, editing it! Docstrings and/or comment headers could be added if you really think they'd add value, such as describing what it is this file does. > 2. Why all the imports? FrmBase seems to be the only one needed, and I am > not Ok, the 'import os' isn't needed. Must be a holdover from something subsequently removed. But the other imports are needed. See initProperties(). > 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. > 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? > 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. Actually, that page was removed. Edit line 753 in AppWizard.py to set useFieldSpecs to True. Notice that your application has far fewer files, and you can edit the field/column definitions inside ui/fieldSpecs.fsxml which will propagate to pretty much the entire UI. There are pros/cons to each way, and I think each is valid. Use what you like the most, but the non-fieldspecs way will give you a much better feel for how to write actual Dabo code, and will give you more control to make the customizations you want, and to scale up as you go. > 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". The code is here in the FrmEvents subclass so that the developer can see what steps need to happen in a non-abstract way, and to easily override or modify the behavior. For example, if you want a child bizobj you just write the python code to do that underneath the instantiation of the primaryBizobj. Again, this generated code isn't meant to be static, it is meant to be customized. When making a new app, I'll start with the AppWizard. But then I'll modify, tweak, add, remove and end up with something much more than what the AppWizard did for me. Think of the AppWizard output as one honking demo showing you how to interact with the DataNav framework. DataNav is a set of classes in dabo/lib/datanav that build on top of dBizobj, dForm, and others. Did that help or hinder? :) -- pkm ~ http://paulmcnett.com _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-dev
