Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

anydata::format::htmltable(3pm) [debian man page]

AnyData::Format::HTMLtable(3pm) 			User Contributed Perl Documentation			   AnyData::Format::HTMLtable(3pm)

NAME
HTMLtable - tied hash and DBI/SQL access to HTML tables SYNOPSIS
use AnyData; my $table = adHash( 'HTMLtable', $filename ); while (my $row = each %$table) { print $row->{name}," " if $row->{country} =~ /us|mx|ca/; } # ... other tied hash operations OR use DBI my $dbh = DBI->connect('dbi:AnyData:'); $dbh->func('table1','HTMLtable', $filename,'ad_catalog'); my $hits = $dbh->selectall_arrayref( qq{ SELECT name FROM table1 WHERE country = 'us' }); # ... other DBI/SQL operations DESCRIPTION
This module allows one to treat the data contained in an HTML table as a tied hash (using AnyData.pm) or as a DBI/SQL accessible database (using DBD::AnyData.pm). Both the tiedhash and DBI interfaces allow one to read, modify, and create HTML tables from perl data or from local or remote files. The module requires that CGI, HTML::Parser and HTML::TableExtract are installed. When reading the HTML table, this module is essentially just a pass through to Matt Sisk's excellent HTML::TableExtract module. If no flags are specified in the adTie() or ad_catalog() calls, then TableExtract is called with depth=0 and count=0, in other words it finds the first row of the first table and treats that as the column names for the entire table. If a flag for 'cols' (column names) is specified in the adTie() or ad_catalog() calls, that list of column names is passed to TableExtract as a headers parameter. If the user specifies flags for headers, depth, or count, those are passed directly to TableExtract. When exporting to an HTMLtable, you may pass flags to specify properties of the whole table (table_flags), the top row containing the column names (top_row_flags), and the data rows (data_row_flags). These flags follow the syntax of CGI.pm table constructors, e.g.: print adExport( $table, 'HTMLtable', { table_flags => {Border=>3,bgColor=>'blue'}; top_row_flags => {bgColor=>'red'}; data_row_flags => {valign='top'}; }); The table_flags will default to {Border=>1,bgColor=>'white'} if none are specified. The top_row_flags will default to {bgColor=>'#c0c0c0'} if none are specified; The data_row_flags will be empty if none are specified. In other words, if no flags are specified the table will print out with a border of 1, the column headings in gray, and the data rows in white. CAUTION: This module will *not* preserve anything in the html file except the selected table so if your file contains more than the selected table, you will want to use adTie() or $dbh->func(...,'ad_import') to read the table and then adExport() or $dbh->func(...,'ad_export') to write the table to a different file. When using the HTMLtable format, this is the only way to preserve changes to the data, the adTie() command will *not* write to a file. AUTHOR &; COPYRIGHT copyright 2000, Jeff Zucker <jeff@vpservices.com> all rights reserved perl v5.10.1 2004-08-17 AnyData::Format::HTMLtable(3pm)

Check Out this Related Man Page

AnyData::Format::XML(3pm)				User Contributed Perl Documentation				 AnyData::Format::XML(3pm)

NAME
AnyData::Format::XML - tiedhash and DBI access to XML SYNOPSIS
# access XML data via a multi-dimensional tied hash # see AnyData.pod for full details # use AnyData; my $table = adTie( 'XML', $file, $mode, $flags ); OR # convert data to and from XML # see AnyData.pod for full details # use AnyData; adConvert( 'XML', $file1, $any_other_format, $file2, $flags ); adConvert( $any_other_format, $file1, 'XML', $file2, $flags ); OR # access the data via DBI and SQL # see DBD::AnyData.pod for full details # use DBI; my $dbh = DBI->connect( 'dbi:AnyData' ); $dbh->func('mytable','XML',$file,$flags,'ad_catalog'); See below for a description of the optional flags that apply to all of these examples. DESCRIPTION
This module allows you to create, search, modify and/or convert XML data and files by treating them as databases without having to actually create separate database files. The data can be accessed via a multi-dimensional tiedhash using AnyData.pm or via DBI and SQL commands using DBD::AnyData.pm. See those modules for complete details of usage. The module is built on top of Michel Rodriguez's excellent XML::Twig which means that the AnyData interfaces can now include information from DTDs, be smarter about inferring data structure, reduce memory consumption on huge files, and provide access to many powerful features of XML::Twig and XML::Parser on which it is based. Importing options allow you to import/access/modify XML of almost any length or complexity. This includes the ability to access different subtrees as separate or joined databases. Exporting and converting options allow you to take data from almost any source (a perl array, any DBI database, etc.) and output it as an XML file. You can control the formating of the resulting XML either by supplying a DTD listing things like nesting of tags and which columns should be output as attributes and/or you can use XML::Twig pretty_print settings to generate half a dozen different levels of compactness or whitespace in how the XML looks. The documentation below outlines the special flags that can be used in either of the interfaces to fine-tune how the XML is treated. The flags listed below define the relationship between tags and attributes in the XML document and columns in the resulting database. In many cases, you can simply accept the defaults and the database will be built automatically. However, you can also fine tune the generation of the database by specifying which tags and attributes you are interested in and their relationship with database columns. USAGE
Prerequisites To use the tied hash interface, you will need AnyData XML::Twig XML::Parser To use the DBI/SQL interface, you will need those, and also DBI DBD::AnyData Required flags ( none ) If no flags are specified, then the module determines the database structure from examining the file or data itself, making use of the DTD if there is one, otherwise scanning the first child of the XML tree for structural information. Optional flags If the default behavior is not sufficient, you may either specify a "record_tag" which will be used to define column names, or you can define an entire tag-to-column mapping. For simple XML, no flags are necessary: <table> <row row_id="1"><name>Joe</name><location>Seattle</location></row> <row row_id="2"><name>Sue</name><location>Portland</location></row> </table> The record_tag will default to the first child, namely "row". The column names will be generated from the attributes of the record tag and all of the tags included under the record tag, so the column names in this example will be "row_id","name","location". If the record_tag is not the first child, you will need to specify it. For example: <db> <table table_id="1"> <row row_id="1"><name>Joe</name><location>Seattle</location></row> <row row_id="2"><name>Sue</name><location>Portland</location></row> </table> <table table_id="2"> <row row_id="1"><name>Bob</name><location>Boise</location></row> <row row_id="2"><name>Bev</name><location>Billings</location></row> </table> </db> In this case you will need to specify "row" as the record_tag since it is not the first child of the tree. The column names will be generated from the attributes of row's parent (if the parent is not the root), from row's attributes and sub tags, i.e. "table_id","row_id","name","location". In some cases you will need to specify an entire tag-to-column mapping. For example, if you want to use a different name for the database column than is used in the XML (especially if the XML tag is not a valid SQL column name). You'd also need to specify a mapping if there are two tags with the same name in different places in the XML tree. The column mapping is a reference to an array of column definitions. A column definition is either a simple name of a tag, or a hash reference with the key containing the full path of the XML tag and the value containing the desired column name alias. For example: col_map => [ 'part_id', 'part_name', 'availability' ]; That will find the first three tags with those names and create the database using the same names for the tags. Or: col_map => [ { '/parts/shop/id' => 'shop_id'}, { '/parts/shop/part/id' => 'part_id'}, { '/parts/shop/part/name' => 'part_name'}, ]; That would find the three tags referenced on the left and create a database with the three column names referenced on the right. When exporting XML, you can specify a DTD to control the output. For example, if you import a table from CSV or from an Array, you can output as XML and specify which of the columns become tags and which become attributes and also specify the nesting of the tags in your DTD. The XML format parser is built on top of Michel Rodriguez's excellent XML::Twig which is itslef based on XML::Parser. Parameters to either of those modules may be passed in the flags for adTie() and the other commands including the "prettyPrint" flag to specify how the output XML is displayed and things like ProtocolEncoding. ProtocolEncoding defaults to 'ISO-8859-1', all other flags keep the defaults of XML::Twig and XML::Parser. See the documentation of those modules for details; CAUTION: Unlike other formats, the XML format does not save changes to the file as they are entered, but only saves the changes when you explicitly request them to be saved with the adExport() command. AUTHOR &; COPYRIGHT copyright 2000, Jeff Zucker <jeff@vpservices.com> all rights reserved perl v5.10.1 2010-01-03 AnyData::Format::XML(3pm)
Man Page