2000-08-11 Darren Duncan <perl@DarrenDuncan.net>
* Release 1.1
* In summary, I largely re-wrote the "core" of the program, namely "CGI::WPM::Globals" and "CGI::WPM::Base", so that they were more elegant, easier to use, and more capable. In addition, much of the public interface for Globals was changed, and the constructor for Base was changed. The other "CGI::WPM::*" modules except for "Content" were updated to be compatible with the new core, including offloading some of their work to it. The non-CGI::WPM modules did not change significantly. Despite the code changes, the new modules are mostly backwards compatible with the "web site" data files for libdwg 1.0. Only the "main program" (such as default.pl) and possibly a site preference file for each "web site" needed changing.
* All CGI::WPM::* modules updated to version 0.2, and CGI::WPM::Content had its number lowered from 1.0 so that the whole set had version number parity.
* CGI::EventCountFile updated to version 1.01 because a new method, delete_all_keys(), was added. Minor change to "synopsis" POD as well.
* Class::Singleton is no longer used because that needed to use a global variable to operate, which apparently is a no-no with mod_perl.
* Distribution now uses only lexical ("my") variables, with no globals used anywhere (except for $VERSION, @ISA, and $AUTOLOAD). This was also true in version 1.0 except for the global that Class::Singleton used. It is true that many constants are declared outside of subroutines, but they are still file-scoped with "my".
* CGI::WPM::Globals had numerous changes, primarily:
- It can now have several instances because it is no longer subclassed from Class::Singleton. However, the first instance will have to create the others so that each can have a copy of the user input read from STDIN.
- It now explicitely stores some information that was in the generic "preferences" before, such as the site's title and the author's name and email.
- It now gathers and parses the user's cookies.
- It now stores the initial user input gathered from the query string and POST submissions separately, so that the caller has consistant access to both and can do more powerful things with less complicated code. For example, session-scoped query string parameters can be persistant across form invocations by using self_url() as the "action" parameter in the form, so that the form fields only have to worry about their own and not things they have no interest in.
- A new method called self_post() works like self_url(), except that it makes a simple form with one button whose "action" preserves the query string and which contains hidden fields corresponding to all the POST data. This is better than storing POST data in a query string for the call back because the data may be too large to fit in one. There is also a self_html() method which adaptively returns either a normal hyperlink or a form depending on whether or not there is any POST data.
- It now manages a "site resource path" (srp) which is a virtual file system whose root corresponds to the folder that all the site's data files are in. When CGI::WPM:: modules want to "change directory", they give the vector to Globals, which takes care of details. When such modules want to access a file, they ask Globals to translate their srp-based file name into a normal file-system path which they use to make their filesystem requests. Before, said modules had to ask Globals for the current system directory and add the vector themselves.
- It now manages the "virtual resource path" (vrp), which is a virtual resource directory used for constructing new urls (and often stored in a persistant query string parameter), much like the changed srp. The vrp is an efficient way for users to specify one of an unlimited number of "site pages" they want in an environment where a single script url is delivering all of them.
- It now handles "preference" gathering and management for all parts of the program, not just the "main site" ones; before, Base was responsible for the individual pages' prefs.
- It now handles more details of compiling and sending e-mails such as the addition of headers telling the e-mail recipient why they got it, whereas the calling code had to do that before.
* CGI::WPM::Base and all subclasses (WPM modules) now take a single parameter in their constructors, an initialized Globals object, instead of two, which had been the physical directory that module starts from and the local preferences for the module.
* It is now expected that the local preferences for a WPM module are now provided to it via the Globals object, rather than the module taking care of its local prefs by itself.
* A WPM module can now inherit preferences from its parent (calling WPM), which is useful if many children need much of the same info; providing a preference with the same name directly to a child will hide the inherited one, however, in the same manner that more locally scoped program variables with the same name hide more distantly scoped ones.
* New module CGI::WPM::Redirect has been added, so that now issuing explicit redirection headers for external-link-callbacks can be accomplished with the same versatility as issuing other content like static pages or forms. Before, redirections were handled by CGI::WPM::Main, which acted under a specific circumstance only (vrp="external").
* New module CGI::WPM::Usage has been added, which replaces functionality originally done by CGI::WPM::Main after it called other WPM modules to make page content. Now the same thing is accomplished by calling Usage and instructing it to call the content-making WPM modules itself (via its preferences). As a result Usage gains benefits of services that Base provides, and it can also be located anywhere in the page hierarchy, meaning that usage tracking can be restricted to certain areas if desired rather than the whole site.
* Usage tracking is now smarter than before, separating referring urls between popular search engines, normal sites, and "junk" (non-http urls like those from online news readers). In addition, query strings from search engines are removed, thereby consolodating urls from an engine, and the keywords are extracted into their own list, so you can see the popular search words that were used to find your site.
* The kludge module named CGI::WPM::Main is no more, and its functionality has gone into other places. Now that Redirect and Usage are split off, there is no practical reason for what remains to be a module. It is far better for the "web sites" main program (such as default.pl) to handle details of initializing Globals, as well as printing the result to STDOUT on its own, because it gives the main program a lot more customizability for how the overall program operates, as it should. Also, most of what went in the "main site preferences" (such as site_prefs.pl) is now provided by the main program explicitely, so that prefs file has less of a reason to be (but can still be used).
* CGI::WPM::MailForm and CGI::WPM::GuestBook now keep persistant query string data in the query string, rather than trying to put them in hidden form fields. This lets the URL that the user sees for the form's "page" to stay consistant rather than the vrp suddenly disappearing from view.
* CGI::WPM::SegTextDoc modified slightly such that the segment number portion of the user vrp is modified to have leading zeros, which helps the relevant page-view items in usage e-mail reports to sort properly (not 1,10,11,2 anymore).
* May be other minor changes, but it won't affect the site data.
2000-07-23 Darren Duncan <perl@DarrenDuncan.net>
* Release 1.0.
* Original release to CPAN.
* The distribution name of "libdwg" was chosen.
* Contains these 15 object-oriented modules:
Class::ParamParser 1.0
HTML::TagMaker 1.0
HTML::FormMaker 1.0
CGI::HashOfArrays 1.0
CGI::SequentialFile 1.0
CGI::EventCountFile 1.0
CGI::WPM::Content 1.0
CGI::WPM::Globals 0.1
CGI::WPM::Base 0.1
CGI::WPM::Main 0.1
CGI::WPM::MultiPage 0.1
CGI::WPM::Static 0.1
CGI::WPM::SegTextDoc 0.1
CGI::WPM::MailForm 0.1
CGI::WPM::GuestBook 0.1
* The first 7 modules have complete POD in them, the other 8 do not. POD will be added to the others when I have time.
* These modules all require Perl version 5.004.
* These modules require the following non-standard modules:
Class::Singleton 1.03
HTTP::Headers 1.37
Net::SMTP 2.15
* Contains a demo "web site" as well, based on my personal web site. It contains multiple static pages, e-mail forms, guest books, and tracks usage.
2000-07-08 Darren Duncan <perl@DarrenDuncan.net>
* Registered myself as a CPAN developer, author name DUNCAND.
* Too many small changes, module renaming, and documentation updates between May 15th and July 22nd to count. But I don't need to detail these since no one else was supposed to be using the development versions anyway.
2000-05-29 Darren Duncan <perl@DarrenDuncan.net>
* Announced the prerelease distribution to comp.lang.perl.modules so that they can give me feedback on it. Some people looked, but no one replied to the posting. It was available on my web site.
2000-05-15 Darren Duncan <perl@DarrenDuncan.net>
* Completed primary development on the final libdwg distribution.
* Converted both of my personal web sites to use the new modules instead of the first prototype they had been using.
* Announced the prerelease distribution to local groups I am affiliated with, so that they can give me feed back on it. It was available on my web site.
2000-01-28 Darren Duncan <perl@DarrenDuncan.net>
* Began development on the final version of the libdwg distribution.
* All modules based on a template created by h2xs 1.18.
* These were developed under the namespace of "DDuncan::*", to be used until a more suitable and integrated name space could be found.
* New distribution was to keep all the good things in the prototypes, add more good things, and lose the problems in the prototypes.
1999-07 thru 1999-12
* Developed second prototype for some of these modules in the "DynaWeb" name space; they are all objects. This time I dropped CGI.pm and implemented my own user input gathering and HTML generation, but still used Net::SMTP for e-mail. I stopped using CGI because I wanted to make generic predefined but persistant forms, and trying to do it over top of CGI.pm would have been a big kludge; also, several other things I wanted to do needed different user input or HTML behaviour than CGI.pm did. However, I made my replacements with backwards compatible methods and behaviour since CGI's interface was still very good. This second prototype never got finished as is, with only the low-level modules being complete. I never used them for any web sites.
* As a separate but parallel project, I also implemented a complete and generic Threaded Discussion Board object using some of my low level modules *and* CGI.pm. This board is possibly still in use today in a corporate Intranet site.
1999-02 thru 1999-05
* Developed original prototype for these modules under the temporary name space of "DynaWeb::*", named for Dynamic WebSite Generator. This prototype went through 6 partial rewrites during that time. At the end it had all of the major features that libdwg 1.0 has now, but the prototype's implementation was very kludgy in comparison. There was explicit frames support part way through, which was dropped later due to making the program more complex than necessary. Also, the modules started out as function-oriented but ended up as objects. These DynaWeb modules used CGI.pm to do user input parsing and HTML generation, as well as Net::SMTP to handle e-mail. I then used it for a year in 3 web sites.
1998-01 thru 1998-03
* Learned Perl for the first time, starting right in with version 5.
* Some of the code that ended up in libdwg was started as a lab exercise.