2000-08-23   Darren Duncan <perl@DarrenDuncan.net>

	* Release 1.11
	
	* Updated CGI::HashOfArrays to 1.01 from 1.0.  Added method
trim_bounding_whitespace() for cleaning up user input from forms.
	
	* Updated CGI::WPM::MailForm and CGI::WPM::GuestBook to 0.2001 from 0.2. 
User input now has its leading and trailing whitespace removed prior to anything
else being done with it, so fields where users may have entered a space or return
by mistake don't register as an error when the field requires content to contain
visible characters.
	
	* Updated CGI::WPM::Usage to 0.21 from 0.2.  Changes mostly reflect how
referring urls are tracked, in the following ways:
		- search engine keywords cleaned; non-alphanums trimmed from ends
		- search engine domain filtering now only matches complete domain
segments (bounded by "." or "/" or edge of string); before, "lo" matched "hello".
		- added usage pref "seul_sekw" (HASH ref) so that the caller can now add
their own search engine domain fragments that they want filtered, and with each
they would indicate the query param the se puts search keywords in.  The built-in
list had less-popular members removed, as the caller can now provide these if
they wish.  Both lists get combined.
		- added usage pref "ref_junk" (ARRAY ref) so that the caller can now add
their own url fragments that they want filtered to the junk file.  The built-in
list now only filters urls that don't begin with "http://".  Both lists get
combined.
		- default misc env vars no longer includes HTTP_ACCEPT* or PATH.  The
associated pref "env_vars" replaces the built-in list if provided.
	
	* Updated CGI::WPM::Content and CGI::WPM::Globals to 0.2001 from 0.2.  Now
there are no specific versions of HTTP::Headers (1.37) or Net::SMTP (2.15)
required in their code, since it is very possible that earlier versions from what
I tested will work; however, the POD still indicates tested versions.  Also, the
POD now assumes that both latter modules are part of the standard Perl install
rather than non-standard; if your distribution doesn't, then you need to add
them.
	
2000-08-12   Darren Duncan <perl@DarrenDuncan.net>

	* Release 1.1001
	
	* Made sure the README and ChangeLog files were entirely word wrapped, as the
second in particular hadn't been and was difficult to read.
	
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 from 0.1, except for CGI::WPM::Content, which had its number lowered to 0.2 from 1.0 so that the whole set had version number parity.

	* CGI::EventCountFile updated to version 1.01 from 1.0 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 (v0.2) 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 (v0.2) 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.
	