Hi Sam Here are a few ideas which would result in minimal changes to H::T which would allow others to use it in different ways. Note that in most cases I have working code which implements these ideas.
Bugs: ---- - Use "UNIVERSIAL::isa(...)" and "SUPER" in the appropriate places so that sub-classes work correctly. Optimisations ------------- - Allow output()ing use a scalar reference. This allows the ref to by used by further instances of H::T (or other code), thus saving a copy of the text buffer. - Optimise H::T::LOOP's output() method. It current contains some 'if' checks that dont need to exist. - Use a more powerful regular expression to chunk up the template. Since Perl's regex parsing is quite fast, the parsing of a template is quicker since the chunks now always begin with <TMPL_ (rather than simply splitting on '<' - Provide a profiling option which dumps some profiling statistics. This can be used to enhance H::T performance. [ This is how I was able to determine where to look for the performance patch. ] - Make Vanguard compatibility available as a filter rather than part of Template.pm - Provide a method where a hashref can be passed in as the value-type for a param, so that it self-expands into the corresponding TMPL_VAR's / TMPL_LOOP's. Often data comes out of a database API as a hash-per-row; depending on how the programmer is using H::T, this can minimise data copying. Enhacements ----------- - Modify the ESCAPE module handling so that it dynamically loads the requested module. This would allow people to create their own escape code to suite their specific needs. eg: H::T is often used to output text which is not HTML - in those cases the rules for escaping can be different; or, someone may want to build an escape module that chains existing modules. - Provide hooks to allow sub-classes to implement their own TMPL_xxx syntax. This is particularly useful when a particular H::T::E expression frequently uses a function call -> it becomes possible to promote that function call to become first class TMPL_XXX syntax. This makes it easier on the template programmer and allows the expression to run faster too. - Allow '.' as a template variable. This makes it a bit easier to group similar variables - Allow the '&' and '|' operators in expressions. - Package some predefined / common filters. - Package a preload mechanism for preloading templates into the memory/file caches. - Now that H::T::E supports a unary context, provide some unary operators too. eg: the 'not' operator - Provide TMPL_ELSIF ... This simply makes it easier on the template programmer. And incurs no runtime overhead to boot. - Provide '__even__' when using loop-context-vars. Yes it is redundant but some people's brain hurts when using inverted contexts (ie: TMPL_UNLESS + TMPL_ELSE). In particular, it works well when used with TMPL_ELSIF. - Allow recursive H::T invocations for those cases where people _realy_ want to do <TMPL_INCLUDE <TMPL_VAR>>... [ and thus deal with the consequences of such an act... :-) ] cheers, Mathew Sam Tregar wrote: > > On Fri, 17 Nov 2006, Mathew Robertson wrote: > >> sure thing - see attached. >> >> I have a few other ideas about enhancements which you may or may not >> be interested in - should I furnish a list of ideas? > > Sure, I don't mind taking a look. I'm more likely to be interested in > bug fixes than new features at this point, but I'll try to keep an > open mind. > > -sam ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Html-template-users mailing list Html-template-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/html-template-users
