Revision 57 (by moose, 2010/08/25 03:30:24) add a small amount of debugging info to ACL::DBI::Person 
Rename?: jonrafkind mentioned Tmpl sounds like Temple. I think it rocks as a proper name.

Tasks:
------

Statement Class
----------------
	- Call Functions
	- Fetch Properties
	- stack based operations
	- 


Class/Object class
------------------



Layout: FIXME: outdated
=======

Tmpl/Template.pm ->
	Tmpl/Parser.pm ->
		Tmpl/Tokenizer.pm
		Tmpl/Tree.pm
		Tmpl/Cache/File.pm
		Tmpl/XMLTree.pm ->
			Tmpl/XMLTree/Parser.pm ->
				Tmpl/XMLTree/Node.pm
			Tmpl/XMLTree/Walker.pm ->
				Tmpl/XMLTree/Node.pm
		Tmpl/Template/Compiler.pm ->
			Tmpl/XMLTree/Walker.pm
			Tmpl/Template/Expression.pm ->
				Tmpl/Template/Expression/Compiler.pm


misc ->
	Tmpl/ParserOld.pm
	Tmpl/Template/Executor.pm
	Tmpl/Template/Expression/Class.pm
	Tmpl/Template/Expression/Parser.pm
	Tmpl/Template/Symtab.pm



Steps: (user acesses 'http://site/foo')
------

FIXME: this is all wrong....

server executes tmpl.pl?page=foo
tmpl.pl creates a Template object seeded with name 'foo'
Template.pm checks the Page cache for useable data ->
	yes -> return it right away (re rendered html)
	no  -> Check Parser cache for pre compiled template code ->
		yes -> run code, cache results (if aloud), return rendered html
		no  -> fall back:
Template.pm creates Parser class to parse page template[s],
Template.pm creates Compiler class and hands off Parser tree to it
	Compiler.pm compiles template
Template.pm caches template code
Template.pm runs the compiled code
Template.pm caches the rendered page, and returns it.


Template.pm needs a way to smartly invalidate either the page or parser cache
	both in the perl api, and the pages themselves need to know how to do it.

Template.pm also needs to handle error codes (403, 404, 500?)
Template.pm also needs user rights and permissions. ->
	use the  tag for that, maybe ...
		though the auth should be in the module implementing the base feature...





==========================================

Symtab seems likely broken, it'll never be called with a dotted variable string anymore.
_local_lookup is essentialy obsolete.

==========================================


Engine needs to support various modules,

Configuration?
User/Group ACL

ACL module (pam, mysql, ldap, etc) (user/group stuff)
Cache module (file, bdb, memcached)
Session module (using cache module?)
UI (MVC) modules
App (wiki, forum, news) modules

URIHandler
CacheHandler
ACLHandler
SessionHandler

fetch: http://site.com/path/page/info?query


URIHandler is no longer a baseclass for apps or anyhing. it just grabs templates based on the uri.
App modules setup "dynamic variables" for pages to use.

Dynamic Variables just create a new object (singleton) when referenced, typically they are App Singletons.
 - apps register a variable thats a reference to a sub, and the sub is called when "get"ed

 - Do I just make modules provide a Symtab::Class::TYPE class?
  - _ref would check %Classes first, then return a Class object of some sort if it matches an existing Class name?
 - Or theres a %DynVars map to call a function provided by the Module


imagine Forum.thread(id) returns a parsed template tree, and it gets inserted verbatim...
- should this be possible?
- should this be nessesary?


this would pass a lot of the rendering to the Forum module, which would have to pull in other templates to deal with stuff...



	
		...
	




Forms:
	Need to cache the form rules per page/form, so the post handler can easily fetch them.



Apps:

Wiki:
	Actions: edit, view, create, delete
Forum:
	Actions: edit, view, create
News:



Template Additions:
===================

NEED to have some way to force invalidate the parser and page caches.
especially the page cache, ie: when logging in.
- or no, upon login the person should get a new session id
  - under all circumstances, I hear it protects against certain man in the middle attacks.
    must make sure to copy all other session keys over though.

Various things need to be stored with the template durring parsing, for later:
   acl lists: $template->add_acl_rule( 'and' => [ qw/ groups / ] ); ???
   css/link lists: $template->add_link(...)



ACL Template Rules:  ???


 page here  ???



   
       {Temple.redirect('login')} 
      
   
   
      ...
      
       
      
   


That acl tag has to insert the code above the main output, to check for the specified rules
but it seems like the entire page will have to be run just to make sure stuff included
from other templates, or added to via Modules or Apps will actually take effect.

An app like a wiki should beable to ask the system to verify the user is in some group,
but it has to happen in the compiled code itself.

That is the hard thing, its only once the Template::Compiler module is working on the parsed XMLTree
that the engine even thinks things are special.

It might be possible to /steal/ acl tags from included/wrapped/whatever pages.

http://admin.tomasu.net/accounts

   
      Accounts
      
   
   
      
         

      
   


Ok, when a template calls into a module via an expression, things happen at run time,
not compile time, so that problem should be "solved".
 Or is it, the module may want to restrict access, and it can't by that point...
  Or does it matter? they can just not return any info if they can't...

when a template uses a module's tags, the module must absolutely not do anything that
expects to change or use any state at compile time. It has to do as much work as possible
at run/eval time.

this is the tough part... When a compiled page is pulled from the cache, any state that modules
may have wanted to setup won't exist, so it can't be done at compile time.


Ok, pretend forum App. It will want to setup some RSS feeds, some CSS files, and maybe REL links.

type 1 has the app registered directy with URIHandler:
 URIHandler passes PATH_INFO/QUERY_STRING/POST_ENV to App::Forum (forum).
 forum will take that info, and load a given template[s] based on what-ever.

in type 1, the Forum will load templates, and sets various state for the template to deal with
things like the forum info.

    (I don't think type 2 will ever work given the structure of temple)
    (not only that, it means doing more programming in the templates than should be needed)
    (actually it should work ok, but a bit backwards at any rate, just do type 1)
type 2 has URIHandler loading full page templates directly, and invoking modules
 URIHandler loads a template directly, and the template invokes the App::Forum for various functions.
 
say /forum/xxx loads /forum.tpl 


   
      
      
   
      





or:




path of '/' or no path would be the fallback if no prior mapping matches.

==

How to use Tmpl in .psgi?

=

use Tmpl;
my $temple = Tmpl->Inst(config => 'blah');

my $sub = sub {
   my $env = shift;
   $request = $temple->request($env);
   $temple->dispatch($request);
   return $request->finalize;
};


= 

now with cgi?

use Tmpl;
my $temple = Tmpl->Inst(config => 'blah');

my CGI;
my $q = new CGI;

my $request = $temple->request($q);
$temple->dispatch($request);

print $temple->finalize;


----