Nate Lowrie wrote: > On Mon, Jul 14, 2008 at 10:31 AM, Ed Leafe <[EMAIL PROTECTED]> wrote: >> On Jul 14, 2008, at 10:51 AM, Nate Lowrie wrote: >> >>> This is meant to be a discussion and a feature request. In designing >>> my Dabo apps, I love how I can add my bizobjs to the form and then I >>> just need to set a controls DataSource to the table to grab data from >>> and the Form automatically finds the bizobj reference. However, this >>> breaks down for dialogs. Dialogs don't keep track of Bizobj >>> references. I use dialogs for data entry and edit. >> Dialogs are not meant for data entry and editing. They are for short >> interactions, not for extended editing. > > I would argue differently. For example, the appointment dialog in > Outlook or Sunbird/Thunderbird. The example in my application: User > has a customer grid that they can sort and search. They find the > customer they want and they need to edit the address. So, they double > click on the customer entry in the grid and up pops a dialog with > fields for customer information such as First Name, Last Name, Address > fields, etc. Are you thinking these should be Forms, because I refer > to them as dialogs? Am I supposed to design my app differently? If > you still can't picture this, I can do a short screencast.
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. >> Or you could say "form.myBizobj". BTW, it seems odd that you are >> marking the bizobj reference as private by using a leading underscore >> when you want to expose it to your controls. > > self.Form from a control on a dOkCancelDialog returns None... Are you instantiating the dialog with Form as the parent? >> But since dialogs are not meant to hang around, the way to deal with >> data is to pass in what you need, set the controls to those values, >> and then query the controls for the values after the dialog is hidden. > > I understand that dialogs are not meant to hang around. But, it would > be nicer to be able to bind DataSource and DataField to a bizobj > reference then to pass the values in and read them back out. It just > seems like I can use the Framework the way it's intended for Forms but > need to design things differently with dialogs. You can bind your controls to the bizobj like you want already. Your dialogs just don't automagically have the bizobj information. 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. >>> All of this is rather unfriendly, especially for a Framework that >>> prides itself on creating data aware apps. >> It also prides itself on not trying to be all things for all possible >> uses. Part of the philosophy of a framework is intelligently limiting >> choices; when you find yourself fighting the framework, it's a sign >> that you either need to re-think your approach or you need a different >> framework. > > I get the philosophy of a framework and yes, I don't like fighting the > framework. However, what I was/am doing for UI design was how I did > it in other languages and with wxPython. How do they handle this in > VFP? > > On another note, I would argue for consistency across the Framework. > Isn't a dialog just a modal form? Both dDialog and dForm subclass > FormMixin, but the bizobj awareness is reserved strictly for non-modal > Forms (by being in BaseForm class). Why can't dialogs be bizobj > aware? Is it too much of a performance hit? 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. 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]
