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. > 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... > 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. >> 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? Nate L. _______________________________________________ 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]
