iain duncan wrote: > On Thu, 2007-16-08 at 13:02 -0700, Paul McNett wrote: >> iain duncan wrote: >>> Hi Dabo folks, I am checking out options for a python fat client to a >>> python backed ( turbogears/pylons ) restful web service. I have my web >>> service command line client working ok, defined as various model classes >>> that look a lot like an sqlalchemy or sqlobject orm. I've always liked >>> using raw wxPython for my hobby hacking but am wondering if dabo could >>> speed up the process of building forms and doing simple validation for a >>> fairly generic business tool. If anyone has done or tried similar >>> things I'd love to hear success/horror/warning stories. >>> >>> So in dabo I want to use my custom model in the backend that will do >>> stuff like: >>> >>> - make beautiful form for entering new client >>> - validate a form for entering a new client >>> - save through my webserviced backed model instead of the usual dabo db >>> - get results from the web service as xml, parse with elementtree, >>> display results in beautiful ouput > > Thank you for the detailed reply! > >> I would say Dabo can live up to your needs. You would use the >> application and ui layers of dabo, and ignore the existence of the db >> and biz layers (you effectively already have your own bizobj, the >> webservice client). > > Now, the biz layers are what hold business rules, correct? So would it
Yes. > be possible to also use the biz layer but have it interract with my > model? I would like to put simple rules in the client to avoid the delay > of round trip server calls that are only going to get errors. I realize > this means my rules will need to be in two places, but that should not > be too bad if both apps are able to use the same python modules. You can do that, but as it is currently implemented, dBizobj assumes it is dealing with a classic database at the db layer. In fact, to instantiate a dBizobj you pass it a db connection. However, you could make your own subclass of dBizobj, overriding such methods as: save(): save the current record saveAll(): save all changed records new(): new record first(): move to first record last(): move to last record next(): next record prior(): prior record getFieldVal(): get the value of the field in current or passed record # setFieldVal(): set the value of the field in current or passed record # This would actually be the best way to go, as you could then do the standard bizobj data binding at the ui level, making textboxes, checkboxes, grids, etc. using e.g.: grd = dabo.ui.dGrid(frm, DataSource=bizCustomers) grd.addColumn(DataField="company_name") grd.addColumn(DataField="address1") ... >> Dabo has data-bound ui controls, that don't need to be bound directly to >> db data, but can be bound to your own properties or functions as you >> need. You'd probably build a lightweight wrapper around your webservice >> client to bind your ui controls to. > > Cool, that was precisely what I was thinking. I got that working in a > simple form with a raw wxPython list, but I expect that in this > situation Dabo provides a lot of the views I would just be making by > hand in wxPy You'll still need to design your UI. You have a couple options: 1) By hand using Python code (save .py files) 2) Use the Class Designer to visually lay out your forms (save .cdxml files). Each has its own set of pros/cons. Each is fairly straightforward. Coding by hand has you typing more and using the class designer has you pointing and clicking more. I don't think there's much if any runtime difference. >> Your form validation, for example, would hopefully call a method like >> validateClient() in your webservice client. The form wouldn't be able to >> close unless that function returns True or the user cancels. No problem >> with any of that. >> >> Saving data: same thing. >> >> Displaying XML "beautifully": I guess I'd need to know what you mean. We >> have an editor widget that syntax-colors xml, but perhaps you are >> thinking that you aren't going to display the xml, but whatever the xml >> represents. If this is the customer data, then yes, no problem. > > Yes, bad writing by me. I did mean displaying the represented data > results in Dabo. The xml would get parsed back into a local model that > dabo would use as a gateway. If you subclass dBizobj as I suggest, you'd override the requery() method to retrieve the xml, and then save it in some sort of structure that your code in getFieldVal/setFieldVal could reference to get/set the needed field value. Conversely, you'd override save() and saveAll() to send the changed data back to the server, in whatever fashion your webservice needs it. > Are there any examples in the docs or wiki of using dabo without the db > backend? Or is it really easy to see where to make the changes? I know the bubblet game uses a bizobj with no db, but I'm not sure how well it applies to your situation. I would just read a bunch of example code using databases (steer clear of AppWizard-generated apps to keep it simple, though) and ask specific questions here. For a dirt-simple 32-line script that creates a database and displays the data in a ui grid, see dabodemo/tutorial/dbEditableGrid.py. Welcome! -- pkm ~ http://paulmcnett.com _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users Searchable Archives: http://leafe.com/archives/search/dabo-users This message: http://leafe.com/archives/byMID/dabo-users/[EMAIL PROTECTED]
