Fixed bug with Makefile.PL by changing Build.PL options.
New option, force_show_cols, which overrides the default setting that if a column has appeared in a header, it won't appear in a row. This can be useful if one has a header which is just the first letter of a column value, and one still wants the full column value later.
Added the --link_suffix argument, to change the suffix used in multi-page reports.
Changed Text::SwiftTemplate to Text::NeatTemplate.
Moved SQLite::Work::Template out and made it a separate module called Text::SwiftTemplate.
Had "CLASS METHODS" twice in SQLite::Work::CGI.
My previous enhancements broke normal output in CGI! Ooops.
To make things easier for some post-processors, I removed the from the prev-next links bit.
Made various changes to make the SQLite::Work::CGI module play nicely with Embperl, such as being able to pass back strings rather than impatiently print things out itself.
Added an "Add Row" button to the main edit form.
Added ability to call a function from a template, with the {&funcname(args...)} construct. If using a function from another package, use the 'use_package' argument to use that package.
Titles now include "An" as well as "A" and "The". Removed underline formatting in the 'html' format style because it's too easy to mess up filenames with it.
Added the ability to customize the thead of the table when doing a report with a table layout. It's up to the user to make sure that it matches the row_template being used.
Added the 'distinct' option, which adds the DISTINCT keyword to the selection. This is active in the sqlreport script, but haven't added it to the CGI selection form.
Change LIKE to GLOB in the search stuff; this means that wildcards are now '*' and '?' not '%' and '_'. Also now case-sensitive.
Also did a quick tweak of some import stuff.
Left out some files from the MANIFEST, oops
An oops moment; forgot to integrate the template stuff for make_edit_table in SQLite::Work::CGI.
Added SQLite::Work::Mail and sqlw_mail to send templated mail sourced from the database. This does NOT use a Perl mail module, but a selection of a couple of external programs, because I wanted to be able to use mutt for the mail.
Moved out some common things (making selections, constructing "nice" column names) into separate methods.
Added a --total option to sqlreport; it prints out the total number of matching rows and exits.
fine-tuning template stuff
Now only shows tables rather than views in edit.cgi
Some improvements to the index-page for split reports.
Now enable one to define the type of input field for editing (well, it enables textarea and text anyway).
Now can also split by a given column with just the first (few letters) of the value, instead of the whole value.
New method do_split_report, and new option 'split_col' to make multi-page reports split by the value of the given column.
Got rid of 'bulk' and 'section_style' options, because they names were too confusing. Replaced them with 'report_style' and 'layout', and added fine-tune params 'table_border' and 'truncate_colnames'.
The --all_pages option to sqlreport generates all matching pages (if the limit is not zero and a real outfile is given)
The --title option enables one to give one's own title for the pages.
Yes, some big huge tests! (Well with a largish database) Also a few tweaks/fixes to a few things, like title formatting. Also added a Delete_Row button to the edit CGI (in addition to the original Delete-from-the-single-row-page button).
Added a default_format, a format-defintion by table+column which is used as the format when using a generated row_template.
Added a 'fieldval' section style, which is similar to the 'none' style for the row_template-generated-in-the-absence-of-a-passed-in row_template, except that, rather than have just the values one per line, it has Field:Value (where "Field" is the column name).
Fixed a bug or so with the CGI, and made more difference between 'compact' and 'large'.
Added a 'none' section_style which gives no section formatting at all, and a default row_template of each value on a line alone.
Added a 'bulk' option which is basically how compact or verbose the given report will be. This replaces the 'verbose', 'hide_thead' and 'short_colnames' options; there are three levels of 'bulk': small, compact and large. Large gives tables with full table headers, and the query and "m rows out of n" bits at the start and end of the report. The 'compact' option is the same, but it gives short column names. The 'small' option gives table with no border, and no extra bits.
Therefore, one can make a non-HTML report with --bulk small and --section_style none plus replacing the --report_template so that it just contains "<!--sqlr_contents-->".
Tried out Text::FillIn and Text::Template and found that rolling my own, very simpler, templating made for quicker processing.
Took a leaf out of other formatters; formatting directives are part of the column-value id.
Instead of using the full power of HTML::TextToHTML, this does extremely simple HTML formatting. We shall see if it breaks, later.
Extended the conditional so that it can (a) check any col and (b) include more than one col-value. This is probably even slower.
Also allowed that the row-template could be a file.
Made a make_row_template method.
Extracted out the get-the-total stuff from do_report and made it a separate method (in anticipation of multi-page report generation)
Now the template stuff is more sophisticated (though not as sophisticated as Text::FillIn) as follows:
Note that these are not recursive, and doesn't give escapes for the {} characters, so you just can't use them. As I said, it's not that sophisticated.
This is probably going to be slower than before.
Added table/para/row "section_style" and simple row templates. The CGI stuff just uses the default row-template.
Removed the dependency on Text::Template; realized this didn't need something that high-powered. Now this just does simple substitution.
Rather than the headers being limited to just one field, now they can be customized with multiple fields and any other stuff you want, by providing a template for each header.
The downside is that you have to provide a template for each header, instead of headers being automatic. But I figure that if you already know what you're sorting by, you already know what you want in your headers. And it's a lot less clunky than the old GenRepAr way of doing headers. One has just split it into two: first say what fields are in the header, then provide a separate header template.