Menu
▾
▴
Re: [Gramps-devel] Request for Comments: Abstractions for Reports
|
From: Alex R. <sh...@gr...> - 2006-01-03 22:52:34
|
Doug, I have just started to catch up on my mail, so I'll need more time to look at your code. From your messages it sounds like it is a great development! The need to duplicate most of the overhead of the report framework always bothered me. If there's an easy way to get this done by the computer and not the programmer then it should be good. Part of the problem the existing system is so tangled and seemingly complex is because we want same functionality when report is used as a standalone report, Book item, and command-line report. We want options to be persistent and if not given then carried over from previous runs. I'll take some time to look at the code and hopefully will have an informed opinion after that. Thanks, Alex On Thu, 2005-12-29 at 23:45 -0500, db...@br... wrote: > Gramps developers, >=20 > I would like to bounce an idea off of you that I think that you will > like. This is some infrastructure built on top of the report and > report options that should make report writing very easy. In addition, > it can work along side the current system so you don't have to use > this if you don't like it (or if you want to slowly migrate all of the > reports over). >=20 > First, I'd like to say that the report system is quite lovely. Very > nice ways of getting device independence. All I did, really, is > abstract the repetitive bits out into objects called Widgets. There > are widgets for styles, fonts, filters, etc. Anything that you need > for making a report would be a widget. >=20 > So, just to remind you of how to write a report, here is the tutorial > on writing reports: >=20 > http://developers.gramps-project.org/tiki-index.php?page=3DReportTutorial >=20 > It is a good tutorial, but there is a lot of stuff to cover that has > to do with the overhead of the user interface, and other > mechanics. And, many bits are repeated, especially in dealing with > styles. >=20 > I set out to write a "Hello World" report. I tried to make it as small > as I could, but it was about as long as the tutorial example. So, I > started working out the bits that were the same, and moved all of that > into these widgets. >=20 > Here is a very simple example that doesn't even refer to the database: >=20 > # ------------------ Version 1 > import Report > import ReportOptions > from Widget import StyleWidget > class MyOptions(ReportOptions): > def enable_options(self): > self.enable_dict =3D {} > self.widgets =3D [ > StyleWidget(self, > label =3D _('The style of the text.'), > bold =3D 1, > name =3D "textstyle", > ), > ] > class MyReport(Report.Report): > def write_report(self): > self.doc.start_page() > self.doc.write_at("textstyle", > _("Hello World!"), > 1, > 1) > self.doc.end_page() > # -------------- end version 1 >=20 > That's it. (I actually tried to get rid of the Options class, but that > would require changing some infrastructure.) As you can see, it is > fairly self-explanatory. There is one widget, a StyleWidget, that > defines a bold style, taking the other style defaults. The write_at > method refers to the name of the style. All of the details, including > the GUI and handling of values, is taken care of by the system (just > slightly altered standard methods). >=20 > Ok, but what about getting a value from the user, and going through > the database? Here is a slightly more powerful example: >=20 > # ------------------ Version 2 > class MyOptions(ReportOptions): > def enable_options(self): > self.enable_dict =3D {} > self.widgets =3D [ > FilterWidget(self, > label =3D _("Filter"), > name =3D "filter", > filters =3D ["descendants", "ancestors"], > CheckWidget(self, > label =3D _("Only include living people"), > name =3D "alive", > value =3D 1, > ), > StyleWidget(self, > label =3D _('The style of the text.'), > name =3D "textstyle", > ), > ] > class MyReport(Report.Report): > def write_report(self): > self.doc.start_page() > filter_num =3D self.options_class.get_filter_number() > filters =3D self.options_class.get_report_filters(self.start_pers= on) > filters.extend(GenericFilter.CustomFilters.get_filters()) > self.filter =3D filters[filter_num] > people =3D self.filter.apply(self.database, \ > self.database.get_person_handles(sort_handles=3DFalse)) > count =3D 0 > for person_handle in people: > person =3D self.database.get_person_from_handle(person_handle= ) > death_handle =3D person.get_death_handle() > if not self["alive"] or death_handle !=3D None: > self.doc.write_at("textstyle", > person.get_primary_name().get_name(), > 1, > count) > if count % 10 =3D=3D 0: > self.doc.end_page() > self.doc.start_page() > count =3D 0 > else: > count +=3D 1 > self.doc.end_page() > # -------------- end version 2 >=20 > This version is mostly code dealing with the filter and actual report, > which it should be. (I think that the details of the filter could be > abstracted out, too. Also, this example glosses some logic.) The > FilterWidget takes a list of special names of filters, the common ones > used in all existing reports. This example allows the selection of two > filters. >=20 > So, this extension doesn't require much change. I've implemented a > slight version of this in the calendar report here: >=20 > http://emergent.brynmawr.edu/emergent/GrampsCalendarReport >=20 > Comments, feedback, questions, suggestions, discussion, criticisms welco= med! >=20 > -Doug >=20 >=20 >=20 >=20 > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi= les > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3Dclick > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel --=20 Alexander Roitman http://www.gramps-project.org |