[eluser]esra[/eluser]
Sorry for the slow response in getting back to the this thread (last minute end of the year stuff at work).
DB_session, Form_helper, and URL_helper are external dependencies of Freakauth_light. They are currently loaded by libraries/Freakauth_light.php. They probably should be listed as base package dependencies in the docs along with instructions for autoloading them or loading them from a base controller rather than allowing the library to load them directly. I'm assuming that questions come up about error messages when the user attempts to load those files via autoload.php or from a controller.
The base FAL package appears to consist of:
config/freakauth_light.php
language/Freakauth_lang.php
libraries/Freakauth_light.php
models/userprofile.php
models/usertemp.php
models/usermodel.php
models/country.php
The above files probably should be bundled in their own archive with separate docs. The balance of the files are the example files, and probably should be included in their own sample package file along with their own docs. This should make it easier for the end user to figure out which files belong to which package.
Keep in mind that the sample code is one possible example of implementing Freakauth_light. This is the code that either needs to be rewritten from scratch for your module(s) or converted to a module(s).
Some choices had to be made by the authors as to what view rendering approach to use for views and a choice was made. There is a similar problem with Matchbox module contributions in general because most people prefer to use their own PHP View or Templating solution. In the future when CI moves to being a PHP5 strict framework, this might change because a Renderer interface could be used by the CI core to allow any number of View/Template solutions to be implemented from a single interface with common method names.
If I was to convert the sample code to a single Matchbox module, I would probably change the view loading code first to use whatever approach I was using for the entire application. The balance of the sample code probably would not change much other than using a few coding approaches that amount to personal preferences on my part.
If I was to convert to multiple Matchbox modules (e.g., User, Profile, Registration, Login), I would probably start with getting the entire module to operate as a single module first, then take a try at splitting the code into separate modules.
----------
One last comment about the use of the country table. For internationalization reasons, I would probably replace the existing solution with a country class, country helper, and country language files for the supported locales. The country helper could then polulate a select list with the country names of the current language.
