NAME
Class::DBI::Plugin::HTML - Generate HTML Tables and Forms in conjunction with Class::DBI
SYNOPSIS
# Inside of your sub-class of Class::DBI add this line:
use Class::DBI::Plugin::HTML;
# if you want to use the pager function you will need to
use Class::DBI::Pager; # as well
.....
# Inside your script you will be able to use this modules
# methods on your table class or object as needed.
my $pager = Table::User->pager(20, $cgi->param('page') || 1);
my $html_table = Table::User->html_table(-align=>'center');
$html_table->addRow('User Name','First Name','Last Name');
my %params;
map { $params{$_} =
uri_unescape($cgi->param("$_"))
} $cgi->param();
my ($where) = Table::User->search_ref(
-params => \%params,
-like_column_map => { email => 'sam%' }
);
my ($url_query) = Table::User->url_query(
-params => $params,
-exclude_from_url => [ 'page' ],
);
my $table = Table::User->build_table(
-pager => $pager,
-columns => [ 'user_name','first_name','last_name' ],
-exclude => [ 'created_on' , 'modified_on' ],
-table => $html_table,
-where => $where,
-query_string => $url_query,
user_id => sub {
return qq!<a href="show.pl?$url_query&id=! . shift() . qq!">view</a>!
}, );
my $nav = Table::User->html_table_navigation(
-pager => $pager,
-navigation => 'next',
-page_name => 'test2.pl',
-query_string => $url_query,
);
print "'$nav'\n";
Table::User->add_bottom_span($table,$nav);
print $table;
my $user = Table::User->retrieve(1);
#my $form = Table::User->build_form(
# OR if you want to use the data record to fill in the form
# make the form via a object versus the class.
my $form = $user->build_form(
-pager => $pager,
# -columns => [ 'user_name','first_name','last_name' ],
-exclude => [ 'user_id' , 'created_on' , 'modified_on' ],
-label => { user_name => 'User Name' },
user_name => sub {
return shift() . qq! <a href="view.pl">view</a>!
}, );
print $form;
my $params = { user_name => 'trs80', first_name => 'TRS' };
my $ignore = [ 'last_name' ];
print Table::User->fill_in_form(
scalarref => \$form,
fdat => $params,
ignore_fields => $ignore
);DESCRIPTION
The intention of this module is to simplify the creation of HTML tables and forms without having to write the HTML, either in your script or in templates.
This module is semi-stable, but production use is still not advised. If the maintainer is lazy and this warning appears in a 1.x or greater release you can ignore it.
Feedback on this module, its interface, usage, documentation etc. is welcome.
The use of HTML::Table was selected because it allows for several advanced sorting techniques that can provide for easy manipulation of the data outside of the SQL statement. This is very useful in scenarios where you want to provide/test a sort routine and not write SQL for it.
It is intended for use inside of other frameworks such as Embperl, Apache::ASP or even CGI. It does not aspire to be its own framework. If you are looking for a framework based on Class::DBI I suggest yoy look into the Maypole module.
FilterOnClick
The reason for this module is to provide a generic method of a technique I codifed in 2000 inside some one off CGI scripts. That technique within its problem space produced a significantly easier to navigate database record view/action system for those that used it. While the current status (version .6 at the time of this writing) isn't a complete representation of the tool, I hope that it will provide enough so that others can contribute their ideas on how to improve the design and make it more generic.
The concept, at its core, is relatively simple in nature. You get a table of records, for our example lets assume we have four columns: "First Name" aka FN, "Last Name" aka LN , "Address" , "Email". The FN , LN and Email address are links back to the script that generated the original table. The link holds information that will modify the query. The link can be set to "LIKE" or "ONLY". "ONLY" is an "=" in the SQL statement, the where clause that is created within the module automatically is passed through to the Class::DBI::AbstractSearch module, which is in turn based on the SQL::Abstract module. The "LIKE" is a little more complicated (confusing?) in its setup. The actual like statement is mapped within the code rather then inside of the link, this is most likely inadequate, but made sense at the time.
Back to the example at hand. Lets say the database has 20K records the sort order was set to LN by default. In the FN list you see the FN you are looking for so you click on it, when the script runs it generates a new query that now only shows (filters) records that match that FN. If you click on the FN column a second time the filter based on FN is removed.
The filter of the table is cascading, you can perform it across multiple columns. So if you want to find all the 'Smith's' with email addresses like 'aol.com' you could click first on an email address containing 'aol.com' and then a last name of 'Smith', provided you configured a proper 'LIKE' map.
Currently there are two built in FilterOnClick utilties, ONLY and LIKE, see documention for build_table for more inoformation on using them.
METHOD NOTES
The parameters are passed in via a hash for most of the methods, the Class::DBI::Plugin::HTML specific keys in the hash are preceeded by a hypen (-). Column names can be passed in with there own anonymous subroutine (callback) if you needed to produce any special formating or linkage.
METHODS
html_table
returns an HTML::Table object, this is a public method and accepts a hash as its constructor options. See HTML::Table for valid arguments.
build_table
Accepts a hash of options to define the table parameters and content. This method returns an HTML::Table object.
my $table = Table::User->build_table(
# pass in the Class::DBI::Pager object if applicable
-pager => $pager,
# define the columns (this is also the order)
-columns => [ 'user_name','first_name','last_name' ],
# what columns not to show, useful if you are dynamically
# turning off columns and don't want to alter the columns
# list at the page/script level for whatever reason
-exclude => [ 'created_on' , 'modified_on' ],
# can pass in an existing HTML::Table object, this
# allows for the header to be assigned etc. prior to
# dynamically adding the records from the database
-table => $html_table,
# using the column name as the key you can pass in
# sub routines to dynamically alter the way the column
# is displayed
user_id => sub { return qq!<a href="show.htm?id=! . shift() . qq!">view</a>! },
):The build_table method has a wide range of paramters that are mostly optional.
-columns (array ref, optional) - The list of field names you want to create the columns from. If not sent the order the fields in the database will appear will be inconsistent.
-exclude (array ref, optional) - Don't show these fields even if included in the columns. Useful if you are not setting the columns or the columns are dynamic and you want to insure a particular column (field) is not revealed.
-table (HTML::Table Object, optional) - Allows for you to pass in an HTML::Table object, this is handy if you have setup the column headers or have done some special formating prior to retrieving the results.
-pager (Class::DBI::Pager Object, optional) - Allows you to pass in a Class::DBI::Pager based object. This is useful in conjunction with the html_table_navigation method. If not passed in and no -records have been based it will use the calling class to perform the lookup of records.
-records (array ref, optional) - Expects an anonymous array of record objects. This allows for your own creation of record retrieval methods without relying on the underlying techniques of the build_table attempts to automate it.
-where (Hash Ref, optional) - Expects an anonymous hash that is compatiable with Class::DBI::AbstractSearch The url_and_where_statement method possibly can help you dynamically create these.
-order (scalar, optional) - This is passed along with the -where OR it is sent to the retrieve_all_sort_by method if present. The retrieve_all_sort_by method is part of the Class::DBI::Plugin::RetrieveAll module.
-page_name (scalar) - Used to create the links for the built in 'ONLY' and 'LIKE' utilities
-url (scalar, optional) - passed to the anonymous subroutines that might be available for a particular column.
table_field_name (code ref || (like,only) , optional) - You can pass in anonymous subroutines for a particular field by using the table field name (column). Example:
first_name => sub {
my ($name,$turl) = @_;
if ($turl =~ /ONLY\-first_name/) {
$turl =~ s/ONLY\-first_name=[\w\-\_]+//;
} else {
$turl .= "&ONLY-first_name=$name";
}
return qq!<a href="test2.pl?$turl">$name</a>!;
},Optionally you can use the built FilterOnClick utilities of 'ONLY' and 'LIKE'. The example above is the base of the process, but is provided as a built in accessible by using:
first_name => 'only',The 'only' can could be replaced with 'like' and is case insensitive.
NOTE: If you use 'like' you will need to have a proper -like_column_map hashref assigned in your search_ref call.
build_form
Accepts a hash of options to define the form options. Values can be left blank for the value on keys in form element names if you want to use the form fill in technique described in this document.
my $form = Table::User->build_form(
# assign attributes of the form tag (optional)
-form_tag_attributes => { enctype => 'multipart/form-data' },
-columns => [ 'user_name','first_name','last_name' ],
-exclude => [ 'user_id' , 'created_on' , 'modified_on' ],
# add hidden tags to bottom of form, these values are put
# into the first cell of the table
-hidden => { 'user_id' => '' },
# assign the friendly name for the cell with the form
# element name
-label => { user_name => 'User Name' },
# same as the build_table method, this allows for custom
# handling of a specific field based on the column name
user_name => sub {
return shift() . qq! <a href="view.pl">view</a>! },
);
print $form;html_table_navigation
Creates HTML anchor tag (link) based navigation for datasets. Requires Class::DBI::Pager. Navigation can be in google style (1 2 3 4) or block (previous,next).
my $nav = Table::User->html_table_navigation(
-pager => $pager,
# pass in -navigation with block as the value for
# next/previous style
# "google" style is the default
-navigation => 'block',
-page_name => 'test2.pl',
);
print "'$nav'\n";fill_in_form
Wrapper method for HTML::FillInForm, pass the arguments you would normally pass into HTML::FillInForm.
my $params = { user_name => 'trs80', first_name => 'TRS' };
my $ignore = [ 'last_name' ];
print Table::User->fill_in_form(
scalarref => \$form,
fdat => $params,
ignore_fields => $ignore
);add_bottom_span
Places the content you pass in at the bottom of the HTML::Table object passed in. Used for adding "submit" buttons or navigation to the bottom of a table.
search_ref
Creates the URL and where statement based on the parameters based into the script.
my ($where) = Table::User->search_ref(
# hash ref of incoming parameters (form data or query string)
-params => \%params,
# the like parameters by column (field) name that the
# SQL statement should include in the where statement
-like_column_map => { 'first_name' => 'A%' },
);url_query
Creates the query portion of the URL based on the incoming parameters
my ($url) = Table::User->url_query(
# pass in the parameters coming into the script as a hashref
-params => \%params,
# items to remove from the url, extra data that
# doesn't apply to the database fields
-exclude_from_url => [ 'page' ],
);string_filter_navigation
my ($filter_navigation) = Table::User(
);This method creates navigation in a series of elements, each element indicating a item that should appear in a particular column value. This filter uses anchor points to determine how to qualify the search. The anchor points are: BEGINSWITH ENDSWITH CONTAINS
The items in the 'strings' list will only be hrefs if they items in the database match the search, if you prefer them not to be displayed at all pass in the -hide_zero_match
The allowed parameters to pass into the method are:
-hide_zero_match - Removes items that have no matches in the database from the strings allowed in the final navigation.
-position (optional - default is 'begin') - Tells the method how to do the match, allowed options are any case of 'begin' , 'end' or 'contains'. These options can be the entire anchor points as outlined above, but for ease of use only the aforemention is enforced at a code level.
-query_string (optional) - This is the same as the parameter outlined in build_table above.
-strings (optional, array_ref - default is A-Z) - Array ref containing the strings to filter on.
-column - Indicates which column the string filter will occur on. If you want to provide a filter on multiple columns it is recommended that you create multiple string_filter_navigation.
-page_name - The name of page that the navigation should link to
-seperator (optional, default two non-breaking spaces) - The characters to place between each item in the list.
-align (optional, defaults to center) - defines the alignment of the navigation
-no_reset - don't include the table reset link in the output
form_select
this methods expects the following: -value_column # column containing the value for the option in the select -text_column # column containing the text for the optoin in the select (optional) -selected_value # the value to be selected (optional) -no_select_tag # returns option list only
BUGS
Unknown at this time.
SEE ALSO
Class::DBI, Class::DBI::AbstractSearch, Class::DBI::AsForm, HTML::Table, Class::DBI::Pager
AUTHOR
Aaron Johnson solution@gina.net
THANKS
Thanks to my Dad for buying that TRS-80 in 1981 and getting me addicted to computers.
Thanks to my wife for leaving me alone while I write my code :^)
The CDBI community for all the feedback on the list and contributors that make these utilities possible.
CHANGES
Changes file included in distro
COPYRIGHT
Copyright (c) 2004 Aaron Johnson. All rights Reserved. This module is free software. It may be used, redistributed and/or modified under the same terms as Perl itself.