NOTE: We are redesigning our site, and this page isn't finished yet.
  Click on the Significato Journal page to see the new design.


Top Page
of Site
Top Page
of Journal
Column
Syndication
Public
Speaking
Abstinence Curriculum Free
Software
Contact
Us

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

Click to view WCP's
Resource Catalogue
We invite you to exchange Links with us; for we all benefit from more traffic.
WCP does not have any control over the content of the Google Ads below, and does not necessarily endorse each ad.

Register
your email

for update notification
to the World Community Journal pages!
About WCN & Contact Us
Affiliated
Projects
The FutureWorld
Association
Replace
Property Tax
Campaign
Hawk
Mountain
Films
Do you need a
Public Speaker?
"Peter Brown did an excellent job with the keynote speech. This man is not only capable of speaking to a national audience but he has 'world-class' ability in public speaking ."
Senator Larry Pressler, former US Senator from South Dakota
Click here for information
about booking him as a speaker at your event!



Click on the PayPal buttons above to pay for WCN products or services with a Major Credit Card!