>> 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.
But thats the beauty of OOP - the tweak, add to, or remove is done in the
subclass. I know you guys know how OOP works, but it seems you are mixing in
some cut/paste style oop too. put that code in the super class and give the
app
developer a blank slate to work with. If you have designed things well, most
of
what the app developer will need to do is set properties, and add some code
into
hook methods (I think that's what they are called)
>
>
>
>> 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!
yes. I want something there when I cut/paste it into an email, or print it, or
post it to a web page.
>
> 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.
I don't think useful Docstrings can be generated. but I am thinking: what
info
is available at the time of generation that might come in handy later?
database
name? list of fields and data types? some of this stuff might be worth
jamming
in as comments. Maybe the create table command in the SQL lite syntax.
>
>
>> 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().
ack! missed that before. now I have more to rant about: put that stuff in the
super class!
>
>
>> 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.
>
So the style is: have FrmBase 3 times with some keywords instead of just 2 and
a
dot - odd sense of style :)
>
>> 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?
ack - I forgot the controlling method: x() calls x_pre()/x_execute()/x_post()
_pre() and _post() are empty, _execute() is what does X what you would expect
X() to do. X is nothing more than:
def x_pre(y): return true
def x_execuite(y): do useful stuff, return useful value.
def x_post(y): return true
def x(y):
if x_pre(y):
r=x_execute(y)
x_post(y)
return r
Now in the sub class you can put code in _pre and _post and don't have to worry
about calling .super.
I heard Ed talk about this pattern somewhere. VFE has it everywhere, and it is
kinda nice. however, I have always wondered how useful it really is. The same
thing can be accomplished by having just x(). if the app developer wants more
code, it goes in the subclass doing a self.super() at the appropriate place.
I think the usefulness is readability, but I am not sure the lack of an 'if'
and
'.super()' make it any more readable.
but useful or not, you should be consistent - if you are going to use the
pattern, don't abuse the pattern ;)
rolling Ed's comments into here:
> 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.
It does hurt:
1. it makes the reader think the super class does something.
2. It makes tracing in a debugger harder if you are stepping though the code,
and you have to step into it to see what it does. The warp to some other place
and back is distracting.
>
>
>> 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.
I have to disagree, as strongly as someone with 30 min of experience can. :)
I think you spent too much time editing .spr files and thought that was a good
thing :)
I will have to get back to you after I have spent another 30 min or so.
Ed says:
> 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.
Ok, that explains why the old way was turned off. still skeptical that the
generated code is a good thing.
>
>
>> 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 constant is the 'afterInit templete' that has the name of the table stuffed
into the middle of this line:
primaryBizobj = app.biz.Events(app.dbConnection)
So most of that line and the other 4 lines (and comments) are the same in every
frmFoo.py that was generated.
Why isn't the last line: self.creation() in the super class, right after the
call to afterInit()?
The rest of the code should be reduce a line in
def initProperties(self):
self.BizObjName ="Events"
and then in the super class,
# Instantiate the bizobj:
app = self.Application
primaryBizobj = getattr( app.biz, self.BizObjName)(app.dbConnection)
# Register it with dForm:
self.addBizobj(primaryBizobj)
> 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.
Use OOP the way I say! or ponder my ranting in the hopes that it isn't a
complete waste of time.
my current thought: if what you are saying is true, why subclass? just
generate
a ton of code. Maybe there is a happy medium between OOP and generated
code,
but I don't see it.
>
> 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.
For 'real use' I think there should be something that does something like what
the AppWizard currently does. I have a feeling with some tweaking to the
framework (which *may* render all current project useless) and lots of tweaks
to the AppWiz (which won't harm anything) there will be a lot less code. not
sure what the advantage is. maybe easier to debug. for me anyway. :)
>
> Did that help or hinder? :)
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-dev
