NAME

Activator Development Framework - Object Oriented framework to ease creation of mulit-developer distributed mixed environment perl based software projects, especially Catalyst based websites.

DESCRIPTION

NOTE: This set of modules is under heavy change and active development. Contact the author before using.

Motivation

  • Provide a framework that makes it easy to do OO programming in Perl.

  • Create a centralized configuration that plays nice with other projects using the same framework.

  • Play extra nice with Catalyst, but provide framework for any Perl project.

  • Maintain a strong separation between the 3 parts of an MVC codebase.

  • Provide tools so that crons, command line tools, and web site code all play nice together.

  • Provide I18N that works across all aspects of a project.

  • Provide Database access that works across all aspects of a project. Optionally, force programmers to write SQL.

  • Allow multiple developers on the same or distributed machines to play nice together.

TODO

This section lists known issues and desired functionality.

Activator (this file)

  • Create full project documentation

  • Create Cookbook section

Activator::Registry

  • Complete variable replacement implementation. Some variables should come from %ENV (like USER)

  • support get() of deep keys with indirect notation. eg:

    Activator::Registry->get('top->deep->deeper');
  • Utilize Hash::Merge custom precedence to DEBUG non-existent keys when calling register_hash() with right precedence.

  • Make currently commented out Hash::Merge custom precedence SAFE_LEFT_PRECEDENCE work when mixing/matching types with left or right register_hash()

Activator::Exception

  • Make this thing do dictionary/lexicon lookups, with support in $extra as well.

  • Make full_messagethis take 2 args, update all of Activator.

  • implement as_xml() and as_json()

  • Investigate a way to add the file:line where the exception was thrown into the error message.

Activator::Log

  • create tests for setting default log levels via new and config

Activator::Dictionary

  • enforce realm naming conventions listed in RESERVED WORDS FOR REALMS section

  • make config of 'db_alias' connections consistent with Act::DB terminology

  • Document what lookup returns for DB with multiple cols. Or, consider removing this functionality altogether: make it only do realm,key,value,lang

Activator::Options

  • support variable replacement from Registry

  • Support Conf File Search Path via command line, ENV and Registry. Also, when a config file does not exist or is ignored, warn which search path it was missing/discovered from.

  • Create a lint hash within each realm that has the identical heirarchy as the realm itself, except values are where the variable was set.

  • consider supporting realm specific command line options the same way as ENV

  • support extra config files that can be injected via command line,ENV and Registry. For example:

    * knassar-apache.yml   # user apache config
    * dev-apache.yml       # dev realm apache config
    * project-apache.yml   # project apache config
    * org-apache.yml       # org apache config
    
    via command line : --conf_files=apache,foo,bar
    via env vars     : export ACT_OPT_conf_files=apache,foo,bar
    via yaml         : conf_files: [ apache, foo, bar ]

Activator::Options

  • implement

act-sync.pl

  • Remove the rebates project implementation, replace with real implementation.

  • Utilize Activator::Project, whenever that gets implemented

Catalyst::Plugin::SecureCookies

  • Consider pulling out base64 stuff and utilize an existing lib. Seems a little hoaky as implemented.

Catalyst::Plugin::SecureForms

  • implement

Catalyst::Plugin::Activator::Dictionary

Catalyst::Plugin::YUI

  • Consider implementing some magic to make YUI integration trivail. Should import the YUI (js/css/etc) on the fly with some simple syntax in a template.

Catalyst::Plugin::Activator::Ajax

  • should provide XML or JSON response wrapper. NOTE: this needs research, as there probably is an easy way to do this already.

  • Do not return HTML, or if you have to, place in CDATA

  • allow passing a .tt to xml_response

  • build json_response?

Activator::DB

  • support some sort of SIGHUP to reload the config on the fly

  • Add support for other DBs. specifically, support mysql_auto_reconnect via a config option.

  • support debugging of attr hash in _get_sql()

Activator::DB::SQLFactory

Activator::Memcache

  • Implement a simple wrapper to memcached that utilizes the registry. Should be a singleton with static calls.

Activator::Cron

  • implement

Activator::WWW::Util

  • Research existing modules on CPAN, implement non-existing stuff.

Catalyst::Plugin::Activator::Exception

  • support as_json and as_xml when Activator::Exception does.

  • consider renaming throw to toss or something. Throw dies everywhere else but here.

Catalyst::Plugin::Activator::WWW::Util

  • wrapper for the above

Activator::WWW::AdminTool

  • port the RJ admintool into Activator::WWW::AdminTool

Activator::Test

  • create test wrapper that is Registry configurable

Activator::Test::WWW::Selenium

  • fix up to be Activator ready

Activator::Test::Harness::Selenium

  • fix up to be Activator ready

Activator::Pager

  • implement getter functions to be more OO, instead of direct obj access

Activator::Lexicon

SEE ALSO

L<Activator::DB>
L<Activator::Registry>
L<Activator::Exception>
L<Activator::Log>
L<Activator::Pager>
L<Activator::Dictionary>
L<Activator::Options>

AUTHOR

Karim Nassar

COPYRIGHT

Copyright (c) 2007 Karim Nassar <karim.nassar@acm.org>

You may distribute under the terms of either the GNU General Public License or the Artistic License, as specified in the Perl README file.