NKA - it's considered rude to rate your own module.
Also, please note that clicking through to the module gives you no documentation, even though there is a separate .pod document - you may want to fix this for future releases.
C::G has a nice, human-readable/writeable syntax, and is convenient for managing simple configuration.
However... it can become increasingly frustrating for complex scenarios. Because it returns a bare Perl data-structure, options with single values will be returned as hash-references, and options with multiple values as array-refs. This means that in the case that you don't *know* how many options you'll get back, you have to faff about with flattening list refs etc.
(Helpfully, unless you're running 5.10, whenever you get this wrong, you'll get annoying warnings about pseudo-hashes, but the error may occur somewhere random in your code, leading to more debugging fun).
You might think you know how many values to expect, but it's surprisingly easy to make mistakes on this, especially if you overlay multiple configuration files (site and local, for example). Some settings, such as -MergeDuplicateBlocks might help with this; sadly we weren't using it in our project.
Also, C::G is incapable of outputting "named blocks" (e.g. <page foo.html>). Though the documentation claims that this is functionally identical, it can only emit a much uglier <page><foo.html>.
Simple and effective. Declare your user db module with password as an encoded_column, then just iterate through all of the users with a $user->password($user->password); # it looks like a no-op, but the setting will trigger the password hashing, and you're done!
Much simpler than having to worry about the defaults of encryption and salting yourself, and if you do want to tweak those later, you only have to do it in one place.
HTML::Template is allegedly fine for simple stuff but rapidly gets unmaintainable when you want to do anything more complicated. Maybe you're only doing simple stuff now, but chances are, later you won't be.
Problems I've come across resulting directly from H::T's design decisions in a large templated application include:
* No dot notation, so you end up flattening your data structures. We prefix related keys like "USER_" instead of being able to pass in a hash "USER" and work on that.
* No expressions, so you can't, say, select a tab if its name is the same as another variable. Instead you have to preprocess the list on the perl side and add a variable "selected". If you want to highlight every other row in a list then preprocess in Perl! After all, if you wanted separation of business and display logic, you'd use a templating system.
* No dot notation means you can't handily use objects, hashes, arrays.
* Lack of object access or plugins means you can't easily do localisation in the template and instead have to preprocess in Perl.
* Filtering isn't plugable. You have "ESCAPE=HTML" and "ESCAPE=JS" and, er, that's your lot. I guess you could preprocess in Perl.
* The default (and therefore most commonly used) tags are <> which means it gets highlighted wrongly by most editors, and ignored by the web browser if viewed un-processed, making it harder to debug. Yet the syntax isn't valid XML.
Some of these deficiencies are fixed by HTML::Template::Expr (which apparently the author disapproves of) and various modules which add dot notation, expressions, plugins and the like.
Or you could just use Template::Toolkit which is as easy to use for the simple stuff, and infitely less frustrating for everything else.
There are a few problems in this initial release.
1) It doesn't work. (The module exports WeekOfYear, but the sub is called weekOfYear.)
2) You can't get the Week number for an arbitrary date, only today's date.
3) The module doesn't do ISO week of year. ISO's not the only way to do it (Microsoft uses a different algorithm) but the documentation should specify.
DateTime might look like overkill if that's all you're trying to do, but is definitely the way to go.