FutureSQL Version History
[ Back to the FutureSQL
Page ]
Version 2.4 / October 30, 2001
(small bug and feature release)
- There was a bug in fsql_setup.pl - &make_record_updated_test_field
that caused an 'Editing Conflict' error. The hidden field name
was wrong. I've corrected that.
- Also, in fsql_setup.pl - &record_updated_test, I added some code
to check if the hidden field for checking editing conflicts
exists:
if it doesn't, I skip the test, to make sure that the record can
be edited.
- In fsql_spec_default.pl, I added a paragraph of code to the
update_record and save_new_record pre_op sections, to check for
the existence of a required field array based on the $table_name
variable, e.g: @table_name_required_fields. If it exists,
(usually setup in fsql_dictionary_vars.pl) the script will
check to see if those fields have been filled out, and if they
haven't, will present an error. The subroutine called is:
&check_required_fields.
- modified fsql_setup.pl
- modified fsql_spec_default.pl
- modified fsql_main.cgi (changed version number)
Version 2.3 / October 24, 2001
(important bug and small feature release)
- Added an important bit of code to
fsql_setup.pl - &create_session_id, to prevent
the possibility of endless looping in case
someone forgets to make a 'sessions' directory
for session ids, or in case of any other type
of file write problem during the creation of
session ids (in the &create_session_id subroutine).
In that subroutine, the script checks for $max_write_seconds
(set by default to 1 minute) and if that limit is reached,
the script aborts with an error message. Otherwise, it
would go into an endless loop (it happened to me, and I
had to kill the script process with a 'kill -9 PIDNO' command).
I created the loop during the file creation section, in
order to ensure that the session id file is unique, using
sysopen(FH, $session_file,
O_WRONLY | O_EXCL | O_CREAT, 0600).
If the script tries to create a file that already exists, it
keeps looping, with a new value for the time() section of the
file name, until it finds a unique file name. This would only
come into play if two web users were trying to write a
session id file with exactly the same parameters at exactly the
same second, and exactly the same 'random' number in the file
name. Unlikely, but worth testing against.
So, now, the script aborts if that process takes longer than
$max_write_seconds.
- changed some code in fsql_setup.pl - &connect_to_db so that
session ids are created for public users, mainly so that
my new application 'FutureSQL:Shop' will work properly.
- added a $cart_id paragraph to fsql_setup.pl - &connect_to_db,
also for FutureSQL:Shop (a shopping cart add on to FutureSQL
which should be released by mid November, 2001.)
- modified the following files:
. fsql_setup.pl (&connect_to_db and &create_session_id)
. fsql_main.cgi (changed the version number)
. modified the futuresql.gif file - added a slogan:
'The RAD Web Database Tool'
. changed to the new MySQL logo in the 3 login files
. modified the graphics width setting in the 3 login files
and fsql_admin_menu_template.html and t2.html
. changed the font color in the files:
home.gif, readers.gif, authors.gif, books.gif
. modified the table in admin_menu_extra_text.html
. added secure_login.html as a sample of a secure login
. modified fsql_site_db.pl - added a second $login_page var
for secure login
. added text to fsql_doc.txt
Version 2.2 / October 7, 2001 (medium feature release)
The Big News :-)
- Added Secure Login subroutine
- Added Session IDs with password encryption
See Security Notes.
- Added customized error messages to the 'Zero records found'
section of the &get_records subroutine in the main code.
and a $zero_records_text variable in the fsql_setup.pl file
- Added :!:title:!: processing to &print_message subroutine.
- Added login_page variable to site_db file
- Added tags: site_name, login_page, fast_search_form,
record_updated_test
(added to site_db file and html files)
(for multi-user processing:)
- Added $record_updated_field variable to site_db file, for
record_updated_test
- Added &record_updated_test subroutine and placed it in
update_record.pre_op
- Added &make_record_updated_test_field subroutine and placed it in
edit_record.post_op
- Added :!:fast_search:!: tag to &view_custom_record page
- Added %fast_search hash to site_db file, and $fast_search_form to
action vars
- Added fast_search_processing to top of default spec file
- Fixed some table errors in default qbf html files
- Added color variables to fsql_make.cgi
- modified the following files:
. fsql_main.cgi
. fsql_make.cgi
. fsql_setup.pl
. fsql_site_db.pl
. all fsql_spec_*.pl files
. fsql_action_vars.pl
. html/admin_menu_main_text.html
. all html/*/*_fields.html files
. all html/*/custom.*.qbf_table_end.html files
. all html/*/custom.*.qbf_record_text.html files
. fsql_doc.txt (this file)
. created a new futuresql/sessions directory for session ids
This directory should be set to 777 so apache can write to it.
Version 2.1 (minor bug fix, etc. release)
- Added a shell script and 3 backup sql files, to provide
data for the 'Books and Authors' demo application.
- edited a typo in the login.html file, which pointed to
the wrong script, instead of 'futuresql.cgi'.
Version 2.0 (major stable release)
Read the file Readme.1st (above, and in the tar file), please.
Programmers always do the documentation last, they say, and I guess I'm no
exception. I've decided to release FutureSQL v2.0, even though the docs are
ridiculously sparse, for two reasons:
1. The code is pretty much rock solid, and has been tested in
production environments with my clients for quite some time.
2. Many, many people have asked me, "When will it be done?"
Sigh. :-) Since this is Open Source, and FREE, it's sometimes
hard to get it all done. Anyway, rather than wait for the docs,
here it is.
Anyone want to volunteer to write some great docs?
So, what's new? A LOT!!!! Since these aren't official docs, I'll just run
down as much of a list as I can remember, and work on better docs later.
So here goes:
. created a demo of just about everything, called 'Books and Authors'
(to setup the demo, you'll have to create 3 tables, with appropriate
permissions, etc. See the file 'books.demo.table.stru'.
. changed file names from 'futuresql_*' to 'fsql_*'.
. removed the first key from the dict and spec files (e.g: 'f.1' =>)
. reworked the setup files and added a number of files:
- 'futuresql.cgi' is run, and
- then loads 'fsql_main.cgi' (THE MAIN SCRIPT ENGINE)
- which then loads 'fsql_site_db.pl'
- which then loads 'fsql_setup.pl'
other files are loaded from calls in 'fsql_main.cgi'
(assuming a tag of 'f.1')
- 'fsql_dict_f.1.pl' - (you ALWAYS need a unique data
dictionary file)
- 'fsql_specvars_f.1.pl' - (or 'fsql_specvars_default.pl')
- 'fsql_spec_f.1.pl' - (or 'fsql_spec_default.pl')
(and then..)
- 'fsql_dictionary_vars.pl'
- 'fsql_action_vars.pl'
- 'fsql_user_subs.pl'
. Note that the file 'fsql_setup.pl', as well as the others above,
are liberally sprinkled with notes and comments. I'd highly recommend
reading through the comments and code in all of them.
. added HTML template files so that the coding can be cleanly separated
from the display of data.
. modified 'fsql_make.cgi', which used to just make a dictionary file.
Now it makes the dictionary file, as well as a set of 7 key html files,
(contained in the subdir 'default_html_table'.)
. stripped out as much 'hard-coded' html display values as I could from
the various setup files. Now most of the display values are contained
in the html templates and the file 'fsql_action_vars.pl'.
. Note that there are also a number of 'support' html templates in the
directory 'html' (such as 't1.html'). These files interact with the
code, just like the 'table' based html files.
. created a file called 'fsql_dictionary_vars.pl' which contains
arrays and hashes used by the dictionary files.
. created a file called 'fsql_user_subs.pl', so that custom subroutines
for different sites can be isolated from more general 'futuresql' subs.
. added code to fsql_action_vars.pl and the 'specvars' files to control
the display and usage of data via html templates versus the 'standard'
display that one sees via the 'Administration' menu.
. modified the 'Administration Menu' to make it easier to use, and added
some routines (like database structure display)
. added a 'Home Menu' so that users can place buttons or links to enter
the FutureSQL program from many different 'windows'. This is one example
of the power of FutureSQL - you can use a 'Public' method (without
passwords, allowing searches, etc.) or an 'Admin' or 'Intermediate'
method, and you can go DIRECTLY to a sub-function from a menu button,
if you like. It's ALL CUSTOMIZABLE.
. fixed many things in the main script, now called 'fsql_main.cgi', and
added many small (and not so small) but important functions, including:
- next and previous button tags
- coded the functions for the DISPLAY key in the dictionaries,
which used to be: 'display_process' => 'none'
(see the sub &get_display_field_value in the main file)
This allows the modification of the display of values.
- added html escaping to the edit function, and various
display routines
- added a variable $view_with_html_escape to control above.
. added the ability to deal with JOINED tables, in display mode, and
added the ability to display related fields, while in edit mode
(see the books table in the demo.)
. created the ability to have an unlimited number of customized
'reports', both single line and multi line, including single tables,
and joined tables, using customized queries, custom headers, custom
html etc. (see the 'view_custom_list' function)
. created the ability to 'export' data, via the above list function
. added the ability to turn on or off the sort order and detailed
boolean logic in the 'query_by_form_custom' function. (The boolean
logic selections are still visible from the regular query by form
function.)
. Based on the concept of using the 'public_functions' or
'admin_functions', via a form field, one can add an unlimited number
of customized functions that can access data and spec files. This is
a VERY useful 'hook' into the program. The Home Menu itself is an
example of this, using the form field value
admin_functions_._admin_menu.
<input type="hidden" name="a_"
value="admin_functions_._admin_menu">
. By using the top files 'futuresql.cgi' and 'fsql_site_db.pl', one can
set up a whole series of defaults, and then access the main file
'fsql_main.cgi' from DIFFERENT top files, so that one can have a number
of applications, all using many of the same dictionary and setup files.
. I'm sure I've forgotten many things, but I'll add to the docs as I
have time.
- Back to the Top Open
Source Page
|