Consider reorganizing the Text::MicroMason::* modules into a number of subdirectories.
There are currently over two dozen of them,
and it's bound to get worse as time goes on.
Perhaps separate them by intent: Cache::*,
Finish and test the ParseInfo module to facilitate template introspection.
Rewrite the MOTIVATION section of the ReadMe pod to reflect the shift from an HTML::Mason clone to a more general templating engine that has at least partial compatibilty with quite a few other modules.
Provide a mixin to search for all files matching a given regex to facilitate tree searches and cache pre-fetching.
Ensure template inclusion is always handled correctly.
Possibly provide the current template's location in %ENV.
Add a DHandlers mixin that supports default files.
On file requests,
if file not found,
look for default file.
(Attribute dhandler_name controls name of file to look for.)
Add an AutoHandlers mixin that supports wrapper files.
On file requests,
also search hierarchy for autohandler files.
(Attribute autohandler_name controls name of file to look for.) Build a stack of autohandlers and store it in a mason attribute.
Support ->call_next() to work through the chain.
(I've also gotten a user request for "decorator files" which turns out to be roughly equivalent to the AutoHandler system.)
Add a TemplateDB mixin which shows how to retrieve templates from a database table.
Provides a read_db() method.
Accept a DBI connection as an attribute -- or a reference to a function which will return rows from a sql statement.
Consider how to support caching for templates drawn from a TemplateDB.
Perhaps in addition to the source_file there can be some kind of opaque cache key returned by the prepare method?
Maybe cache values for db templates can be abstracted into closures which are run to retrieve the cached value.
Add a DataCache mixin that provides a pre-configured cache object for use within template code.
Requires cache() method and configuration attributes.
Cache namespace should be based on source file name or arbitrary instance for text compilation.
Alan says: I believe this is intended for use to cache contextual data across template runs?
Is this intended to be persistent across multiple templates (in memory/singleton),
or across multiple process invocations (in a file)?
I use mod_perl,
and this sounds at best not useful and at worst,
Add an InterpretCache mixin that allows caching of the parsed and assembled Perl code for a template file,
akin to Mason's var/obj/ directory.
(This would also allow visual review when debugging the converted code.)
The InterpretCache and CompileCache benefit from using a cache object that checks the keys as filenames to see if the source file has been updated and forces cache expiration; find a way to extract and reuse this capability from Text::MicroMason::Cache::File.
Add a BlessSub mixin that blesses the compiled subroutine.
This would let us add support for template-specific behaviors and attributes.
Override eval_sub() to bless sub before returning.
Attribute bless_sub controls initializer arguments passed to BlessedSub class.
BlessedSub class is base class for blessed template objects.
Provides execute() method.
BlessedSub classes may need their own mixin factory...
To avoid having to define separate mixins for both packages,
perhaps the methods should be delegated from the coderef to the Mason instance?
(This becomes particularly attractive if each sub is automatically getting its own cloned mason instance anyway.)
Add an AttrBlock mixin,
Override lexer methods to parse <%attr> blocks.
Stores attribute definitions in a %once block.
Provides attr() method.
Add a MethodBlock mixin,
Override lexer methods to parse <%method> blocks.
Stores method definitions in a %once block.
Hooks AUTOLOAD to catch method calls.
Consider moving output_sub to a new OutputHandle mixin which accepts a handle as an attribute,
then prints output to it rather than returning the results as a string.
Clarify and document the clone-on-change behavior of prepare() and its effects when making changes to a mason object after compiling a template.
Perhaps we should ensure that we clone every time,
or at least every time that it matters?
Set up a benchmarking tool to compare subclasses with other templating solutions.
Take an example from ApacheBench but execute templates directly rather than via Apache.
Store the expected output in a text file for comparison.
Set up a compliance test tool that compares the output of the various MicroMason mixins with the other modules they emulate. This should be able to use many of the same data files as the benchmarking tool.
Add more templates to samples directory and test them.