Function to generate a clickable tab. ‘text’ contains the text that should appear in the tab. ‘usable’ indicates whether the tab is usable.

If the tab is usable, its background and foreground color will be determined by the ‘usabletab’ class. when the mouse is over the tab the background and foreground colors of the tab will be determined by the ‘mousedovertab’ class.

If the tab is not usable, the tab will use class ‘unusabletab’

Functions to put the headers in place. Probably should be generalized more, than specifically pre-scripting it, the way we do. Should not be called outside of CommonCode, topofpagereport should be called instead.

Functions to put the footers in place. Possibly should be generalized more, but is already pretty short. Should not be called outside of CommonCode, correct_footer should be called instead.

Top of page reporting, simplified by the foo_header functions for HTML pages. It takes the title, description and any additional information, and puts it all in the right place depending on the SESSION variable. This should be expanded out to include $message and $message_error.

Top of page reporting, for CSV pages. It takes only the filename as an input, and spits out the CSV headers.

Footer choice, for html pages. Select the correct footer, dependant on role. This could probably just have the above footer functions, rolled into this, for simplicity sake.

Produce the HTML body version of the information gathered in tables. It takes 4 inputs, the number of rows, the header array, the elements that go into the table, and if this table is the last thing on a page. The switch for the close on how it is called doesn’t quite work yet, and might want to be simplified out, depending on the calling page to do the right thing, dropping it to 3 variables.

I believe the above to be somewhat incorrect, should update this.

Produce the CSV body version of the information gathered in tables. It takes in four variables, the start row, the number of rows, the header array, and the elements that go in the table. It then strips out all of the unwanted characters (html tags, extraneous returns, and other bits) and outputs the comma separated information.

This function presumes multiple calls on the same array informaition. It takes in 4 elements, the start and end row for a table, of the series of tables, the headers which go in every table, and the full array, from which the subset is used. It then prints them nicely.

This function renders the Schedule, Description, Tracks and Bios in their various forms, for their various audiences.

It takes 5 elements:

• format - One of desc, bios, sched, tracks
• header_break - If there is sectional breaks, what it breaks on
• single_line_p - If the sched line is a single line, or includes the descriptions
• elements - the count of the elements to loop over
• element_array - the array of elements to loop over

It returns a (printable, or otherwise mungable) html string.

Pull the information from the database for a report. This should be checked with, and possibly unified with other functions in db_functions file. It takes the query and link to do the pull, title and description in case there is an error, or just no information, and a reportid, so the report can be edited if there is a query error in the report.

Show a list of participants to select from, generated from all participants. Each list is ordered by the sorting key, for html-based and visual-based searching.

It takes three elements:

• selpartid - if there is a selected participant already, set that participant to be “selected”
• limit - how to limit the set of participants returned.
• returnto - the form’s destination, where it should be submitted to.

It returns a form (usually at the top of the page) for selecting a participant in various ways.

This takes the: trackidlist, statusidlist, typeidlist, and sessionidlist, and returns information for RenderPrecis by producing: $sessionid, $trackname, $typename, $title, $duration, $estatten, $desc_good_web, $desc_good_book, $persppartinfo, $proposer IN THAT ORDER.

For the title and descriptions:

• descriptiontypeid/name: 1=title 2=subtitle 3=description
• biostateid/name: 1=raw 2=edited 3=good (only using 3/good for now)
• biodestid/name: 1=web 2=book
• descriptionlang: Only using “en-us” for now.

The prevcon is if we want to search a previous con for the information. This is underutilized, and should be documented more in other places.

RenderPrecis display requires: a populated dataarray containing rows with: $sessionid, $conid, $trackname, $typename, $title, $duration, $estatten, $desc_good_web, $desc_good_book, $persppartinfo, $proposer IN THAT ORDER.

It displays the precis view of the data. This goes hand in hand with the retrieve_select_from_db above.

This should probably be renamed to work with the rest of the renderfooreport nomenclature.

This function will output the page with the form to search for a session.

Variables:

• track: a number signifying the trackid in the Tracks table, or 0 - implying all
• status: a number signifying the statusid in the SessonStatuses table, or 0 - implying all
• type: a number signifying the typeid in the Types table, or 0 - implying all
• sessionid: a sessionid from the Sessions table, limited to this con-instance.

The output varies depending on the permissions of the caller.

Still missing:

• Title search
• Suggestor search

This is similar to select_participant

Generic insert takes five variables:

• link: generic link to database.
• title: page title in case of errors.
• table: which table to submit to.
• array of elements: the fields in the table that are getting submitted.
• array of values: what is ending up in the table

This should probably migrate to db_functions.

Add examples.

Generic update takes six variables:

• link: generic link to database.
• title: page title in case of errors.
• table: which table to update.
• pairedvalue_array: a paired array of updates with all the information to update/set.
• match_field: which fields in the existing table to match on.
• match_value: which elements in the existing table to update, those matching these values.

This should probably migrate to db_functions.

Generic update takes five variables:

• link: generic link to database.
• title: page title in case of errors.
• table: which table to update.
• pairedvalue_array: a paired array of updates with all the information to update/set.
• match_string: the “where” string to match on.

This is more powerful than (and therefore more prone to errors than) update_table_element.

This should probably migrate to db_functions.

Generic delete takes four variables:

• link: generic link to database.
• title: page title in case of errors.
• table: which table to delete from
• match_string: the “where” string that we are matching on. Could destroy all your data.

WARNING: Very Dangerous. Your where string could wipe out the whole table.

This should probably migrate to db_functions.