Nate Lowrie wrote: > On Mon, Jul 14, 2008 at 11:28 AM, Paul McNett <[EMAIL PROTECTED]> wrote: >> Nate Lowrie wrote: >> I think it is natural for this to be a dialog. I happen to use the edit >> page of the main form, but using a dialog to get that info from the user >> makes sense IMO. > > Could you explain the edit page a bit more clearly. Is this a > framework feature?
Run AppWizard to see what I mean. Each form has a pageframe with "Select", "Browse", and "Edit" pages. When you press 'enter' or dbl-click a record in the browse page, you get to edit that record in the edit page. >>> self.Form from a control on a dOkCancelDialog returns None... >> Are you instantiating the dialog with Form as the parent? > > Yes. It makes sense though to have self.Form return the dialog > reference though. Which is does do. I just checked in my app and referencing self.Form from a control on the dialog returns the dialog instance. >> You can bind your controls to the bizobj like you want already. Your >> dialogs just don't automagically have the bizobj information. > > Understood. With Ed's context it seemed like he was saying the proper > way was to just pass everything back and forth and not go through > binding bizobjs. > >> I know I'm into the forbidden territory from Ed's perspective, but I get >> the bizobj reference, and then all works fine. I then either call >> biz.save() or biz.cancel() depending on whether the user hit okay or cancel. > > I do the same thing. I just think it would be a useful feature if not > only were the dialogs bizobj aware, but would also inherit bizobj > instances from their parents. When the user double clicks on a grid > entry, the bizobj for the grid is already set to the record they want > to edit. So, when the dialog pops up, doesn't it make sense to grab > the bizobjs automatically from the parent if the parent is a Form? I > shouldn't need to override __init__ (other ways but this is easiest so > far) so I can pass a bizobj reference. Maybe we could add this as a > property? I don't really see the need. The dialog wouldn't need to know about the form's primary bizobj, most likely, and only one of the other ones, most likely. The appdev should explicitly tell the dialog which bizobj (or datasource) to be interested in. >> Again, I think there's a ticket for this. In my perfect world we would >> refer to forms as frames and from the context of dabo the 'form' is the >> object that exists purely as the mediator between the ui and the biz >> layer. So one could put a form on a frame, on a dialog, or a panel. That >> way you get encapsulation, modularity, flexibility, and portability. > > Reminds me of the way HTML forms work in a sense. The ticket you are > referring to is http://trac.dabodev.com/ticket/1034 Were you still > planning on pursuing an architecture like this? I think it makes > sense. I want to do it, but up until now I felt I was the only one. I thought I was going to need this for something I was working on but implemented it differently, so its no longer critical for me. Paul _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-dev Searchable Archives: http://leafe.com/archives/search/dabo-dev This message: http://leafe.com/archives/byMID/[EMAIL PROTECTED]
