Rich Shepard wrote: > On Fri, 2 Mar 2007, Ed Leafe wrote: > >> Nah, it's not that bad. Once you're familiar with the rules, it >> isn't difficult to make it work. > > Where I got totally tangled was with two concepts: 1) that a cursor > represents a single and complete 'view' retrieved from one or multiple > tables (which is the usual idea of a database cursor), so it needs to be > generated by code for each record to be printed ... I think; and 2) that the > format of the cursor in the application code (as input data) is not the > xml-formatted version require by the template (the .rfxml file) used to > format the input for the reportLab engine.
The concept of "Cursor" from the POV of the Report Writer isn't the same as the concept of a dCursor from the POV of Dabo bizobjs. They are both sequences of dicts, but the dCursor has much more built into it, including the harness necessary to retrieve records from and update a backend database. Eventually, I'd love to throw a dBizobj at ReportWriter, and just work. For now though, it needs a simple sequence of dicts, such as what you get when you call dBizobj.getDataSet(), or when you build it yourself. As far as the xml-formatted TestCursor embedded in the .rfxml, that's just what it sounds like, and only meant to give you test records to preview with while designing the report, so you don't have to connect to actual data at that point. _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users
