HTML Document Object Code
Brought to you by:
pcxuser
HTMLObject README Created by James A. Pattie Xperience, Inc. http://www.pcxperience.com/ You also need to install the following non-perl modules/apps: Apache searchBox - bundled in this package. Follow the README instructions to install. Perl Modules we depend on: Data::FormValidator Date::Manip Installation: tar xvzf html_object-VERSION.tar.gz perl Makefile.PL make make test su (if not root) make install To get the Date and Color Picker libraries and other JavaScript include files: cp -av htmlobject /usr/share/ Install the documentation and example files: mkdir -p /usr/share/doc/libhtmlobject-perl cp -av apache.include /usr/share/doc/libhtmlobject-perl/ cp -av examples /usr/share/doc/libhtmlobject-perl/ vi your httpd.conf file and: Include /usr/share/doc/libhtmlobject-perl/apache.include This will make the included html and js files available to your applications at /htmlobject/ from the website you included the config file at. Internationalization support is now being implemented. The lang and charset values are being set now and default to lang=en, charset=iso-8859-1. The JavaScript Error Handler is currently the only part of the module that it is possible to internationalize. If anyone is interested in making different language versions of the default error handling code, please contact me and I'll be happy to work out how it needs to be done, etc. In the examples directory, the lang.cgi script allows you to test the Internationalization support that is being implemented in the HTMLObject module. Copy lang.cgi, en_lang.pm, and eu_lang.pm to a directory that allows you to run cgi scripts. This is usually /usr/lib/cgi-bin under Debian or /var/www/cgi-bin in RedHat 7.x+. The Basque language is only being used as a test case where the strings are still english but have been pre-pended with *** to allow me to test whether or not the code is working. This is just an example of how you could use the HTMLObject to implement multiple languages support. If anyone can think of a better implementation, please let me know. The sessions.cgi script demos using Apache::Session for storing session info. A database (sessions) needs to be created with the sessions table. If using postgresql (which is what the demo uses), su to postgres, then create the database via: createdb sessions And then create the necessary table via: psql sessions < sessions.pgsql The sessions.pgsql file is in the examples directory. To run this sample program you need Apache::Session version 1.53 or greater installed. The non-buffered.cgi script tests the Base.pm Modules non-Buffering support. The non-buffered2.cgi script tests the Normal.pm Modules non-Buffering support. The debug.cgi script tests the Base.pm Modules debug error handling code. The debug2.cgi script tests the Normal.pm Modules debug error handling code. The HTMLObject::WAP module will generate HDML 3 or WML 1.1 documents for use in a WAP environment. WMLScript 1.1 will be added in the future. See Changes file for latest changes to the HTMLObject's. NOTE: As of 2.06 Steven Brenner's cgi-lib.pl script is now available as HTMLObject::CGILib. It still functions exactly the same way and the same modifications I previously made to make it mod_perl safe are still there. The modified version I created is still available in the examples directory but all sample programs have been modified to use the HTMLObject::CGILib version. The file upload capability of the CGILib module only works from 2.10 onward! NOTE: As of 2.15 you can now specify which HTML version and DTD to work with. It defaults to 4.01/loose. See the man page for FrameSet and Base to see all possible values and the new methods to use (setHTMLInfo and getHTMLInfo). NOTE: As of 2.16, XHTML is now supported in Base, Normal and FrameSet modules. Use the setHTMLInfo() method to specify you want xhtml support and the dtd to use (strict, loose or frameset - based upon the module in question). All generated <br> are now being generated as <br /> so as to be compatible when in XHTML or normal HTML modes. Any comments that would have been generated to wrap style sheets, javascript, etc. are now being conditionally generated as a <!-- --> or <![CDATA[ ]]> pair based upon if we are using HTML or XHTML Doc Types. You can also specify the document Encoding for XHTML documents. NOTE: As of 2.18, Form display and processing code is now available via the Form module. JavaScript Date and Color pickers, cookie methods and form methods are now included in the core distribution. The debian packages will install them into your apache tree (/usr/share/htmlobject/). See the examples/form.cgi script for an example of how to use it. This uses the Data::FormValidator to help do input validation. The CGILib module now accepts human readable sizes for the file upload size. You can specify sizes in M (Megabytes), K (Kilobytes) and B (Bytes) - which is the same as leaving off the indicator. Ex: 4M, 128K, 2048B The JavaScript Error Handler is disabled by default until you specify the e-mail address errors should be sent to! Use the new enableJavascriptErrorHandler() method to set the email, prgName and prgVersion values all at the same time. NOTE: 2.19 fixes the issue where the Data::FormValidator would say that an input of 0 was invalid, even when the validation code says it is valid, by adding the untaint_all_constraints => 1 to the profile if it isn't there and as long as the untaint_constraint_fields option is not specified. Use the parameter dontUntaint => 1, if you don't want this behaviour when calling validate(). NOTE: 2.21 changes the default focus from head to body. This will help stop invalid documents from being generated when you forget to setFocus("body") before $doc->print'ing body related content. NOTE: In 2.24 HTMLObject::Normal->generatePickerCode() and HTMLObject::Form->generate() formEncode() their phrase and -Label values using the formatting sequence (which will disable any XSS vulnerabilities but still allow you to use formatting tags). The parameters and options for the setOnload() method are now invalid and the generated doOnLoad() function does not set parameters, etc. Move your code that used this feature into its own function and call it with the options in the onload() method. The same thing is true for the setOnunload() method and it's generated doOnUnLoad() function. NOTE: 2.25 fixes the error in the Form module when we added our required profile entry and the required array wasn't previously defined, we were adding a literal string instead of the contents of the variable. Added the onbeforeunload support to all relevant modules and documented how to write a function that will work with it correctly. NOTE: 2.26 adds a css file to the /htmlobject web tree so that the css attributes referenced by the createTemplate() method exist. When generate() calls createTemplate() due to no template being specified, it also creates the link tag to pull in the htmlobject.css file so the attributes are defined. NOTE: 2.27 adds lots of user friendly enhancements: - expire time for cookies is now human readable (30 minutes, 1 day, etc.) - Added the setLocation() method to allow setting Location: header. - Added refresh() helper method to simplify the Refresh meta tag generation. - If you specify displayOnExit => 1 in new() for Base, Normal and FrameSet modules, then when your object goes out of scope, if you haven't called display() yet and doNotDisplay = 0, then display() will be automatically called for you. This allows you to not always have to remember to call display() explicitly. If you do decide to not display an object and you start another object for error handling, etc., make sure you call doNotDisplay(1) on the object you aren't wanting displayed, else you will get both HTMLObjects output generated. - validate() now requires the data hash to be passed in, though if you do not specify it, it will default to an empty hash. This is so that the populator widget can properly update the profile. NOTE: 2.28 is the LAST 2.x release planned. The next major version will be a major API breakage in regards to the Form and Widgets modules. NOTE: 2.29 is really the LAST 2.x release planned. It turns out there were enough minor bugs and usability issues that we wanted to get fixed before we totally tore apart the APIs etc. NOTE: 2.30 fixed a dependency in Makefile.PL and is addressing the OSX ACL files that got included in the tarball and break modern make instances.