This module attempts to create dynamic tables that "fold"
By fold it is infered that when clicking on a value in a
column that the data source will be reread and only the
values that match the clicked on item will be shown. We
also allow for multiple folds, which means that if values
from multiple columns are clicked on then the folds will
build on top of each other.

This module will most likely not be generic enough to not
require some advanced confirguration, either inside this
file or via an external script.  Most likely it will
configured via a method as well.

This process attempts to not use cookies, this may change
at some point, but presently a complex URL parsing system
is used and works well.

The resulting table rows are set with an attribute on
object creation and a paging system allow the user to
move to a particular point.

There will be a limited search facility was well in the
initial releases.

A hash for each column to be displayed/handled needs to be
created with the following values:

    action_and_fold - indicates that a field has an action* that
        can happen and it can also be folded   ( 0 or 1 )
    
    add_to_url - extra column values and name that should be
        added to the URL for a column. this covers special
        cases where additional values may be needed when a
        particular action is taken. this is an annon array
    
    align - how should the column be aligned when displayed
        (center, left, right)
       
    allows_direction - is the column sortable by asc/desc
        1 or 0
    
    key_columns - these are the columns that need to refereneced
        for a match when doing an update and in some cases a
        select

    href - page other then present a column should link to,
        by default the "key" will be the URL for these along
        with the current values for folding so the "main" page
        can maintain state.

    modify - this is a subroutine that is run on the values
        returned

    regex - this is how it should be matched from a URL
        generally a base URL is created from the previous
        post, if a column has been folded it needs to
        remove the additional URL data from it so the fold
        is removed.  multiple folds on a single column is
        NOT currently supported

    special_colors (BAD NAME) - a hash with a color as the key
        and an array of strings as values for pattern matches.
        if a column needs to be a particular color for all 
        values matching "fish" this  could be done here.
        each color MUST have a corresponding entry in your
        style sheet. example entry:
            'red' =>  [[ 'hello','hi','greetings'  ]],
            'blue' => [[ 'bye','good bye','see ya' ]],

    table - the database table the value of this column is being
        read from. the database table name in correct case, it
        will be used in the creation of SQL queries(?)
        
    column_header - the name of the header on the final
        output (defaults to the database table column name if null)
        
    url_param - what to look for in the URL, this will most
        likely be discarded in favor for column name instead.
        the url is modified during the table generation to
        change values to the current row or delete an item.
        (original code used abbreviated names in the URL)
        

Notes on the original idea that have yet to be worked
through:
    
Column names need to be followed by ascend/desecending arrows

Previous folds sent must be remembered, that is all folds up to
    this point. This should NOT be done via session data.
    
* action - this is most likely a popup window that contains a small
form from which you can modify the value of the column that it was
clicked in.  a screen refresh is froced after the form is completed
to show the new data

I have modified the DBIx::XHTML_Table module to allow for some of
the features mentioned above, but there is also the need for
an query creation method/class.  I have looked at Reltaions-Query
are there others that someone might suggest?

This module will be stand alone, that is not based on a templating
system or be mod_perl dependent.

The structure of the code is in an alpha/planning stage at this
point.

I have mature working code in the current product, but it
is tied to the needs of that product.

Now for what it does in a quick and dirty def.

1) The columns are in the order you specify to the object on
creation
2) Some columns being links to the "fold" method
3) You are able to add custom columns that were not in the
database pull
4) Columns that had a modify sub in the above mentioned 
hash have been changed as stipulated in that code
5) When you click on say a date in the date column, the query
is modified and only values for that date are retreived.
6) Now you can also click on another column and the query will
be further modified and you will only see values matching that
link (click) and the date you selected before.
7) Clicking on the date column again now removes the date
where from the query string.
8) At the top and bottom of the page are links to all the
pages available, the limit of records per page is set at
object creation.

Part of the proposed new method:

    my $table_params = {
	columns           => $args{columns},
	 # the hash ref that is explained vaguely above
	params            => $args{params},
	 # the URL params - hash ref
	table_rows        => $args{table_rows} || '25',
	 # number of rows to allow on a page
    odd_bgcolor       => $args{odd_bgcolor} || qq~ class="shadedBG"~,
     # bg color - DBIx::XHTML_Table has a better method then this
	even_bgcolor      => $args{even_bgcolor} || '',
    javascript_action => $args{javascript_action} || 'ONCLICK',
     # This determines if a javascript pop up window is
     # ONCLICK or ONMOUSEOVER etc.
    day_offset        => $args{day_offset} || '0',
     # used in current product, may not apply in final module
    debug             => $args{debug} || '0',
     # turns on off debug statements
    dbh               => $args{dbh},
     # the database handle it should use
    _next_page         => '',
     # not for the user
    _previous_page     => '',
    _html              => '',
    limit             => $climit + 1,
     # the LIMIT for the SQL statement
    climit            => $climit,
     # part of the artifact from the old code, not good :^(
    select_start      => $args{select_start},
     # the default begining of the select statement
     # was useful in current product, but might not be in
     # generic module
    column_order      => $args{column_order},
     # columns you want displayed in the order you want them
     # array ref
    date              => $args{date} || $date,
     # date for query if needed currently creates MySQL style
     # dates
    exclude_from_url  => $args{exclude_from_url},
     # which params should not be included in the URL, these
     # are sometimes passed back to the page when doing updates
     # or other things
    default_item_style => $args{default_item_style} || 'regItem',
     # which class is the default for each column
    style_sheet       => $args{style_sheet} || 'style.css',
     # which style sheet to use
    page_head         => $args{page_head} || qq~HTML STUFF HERE~,
     # what should go at the top of every page
    };

The above is based on the current requirements for the
existing product with a couple of new ideas added.