Mathew Robertson wrote:
> 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.
Just to chime in and mention what I would find useful or not.
>
> Bugs:
> ----
>
> - Use "UNIVERSIAL::isa(...)" and "SUPER" in the appropriate places
> so that sub-classes work correctly.
Why should H::T use SUPER?
> 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.
++
> - 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 '<'
I'm not sure I follow. What regex would you use instead?
> - 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
++, or deprecate it and then drop it completely. Sam/Jesse, is anyone still
using that who also upgrades H::T?
> - 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.
I'm not sure I follow here. hashref's are already used for loops. Are you
talking about having something like this:
$tmpl->param(
person => {
first_name => 'Michael',
last_name => 'Peters',
}
);
And then in the template something like this:
<tmpl_var person.first_name> <tmpl_var person.last_name> ?
If so, then HTML::Template::Plugin::Dot may be more what you're looking for.
> 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.
This might be useful, but I'm sort of ambivalent.
> - 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.
Again, possibly useful. Maybe a compelling use case would help spur the
discussion.
>
> - Allow '.' as a template variable. This makes it a bit easier to
> group similar variables
>
> - Allow the '&' and '|' operators in expressions.
You want bitwise and/or? use case?
>
> - Package some predefined / common filters.
like...?
> - Package a preload mechanism for preloading templates into the
> memory/file caches.
++
Krang already does this on it's own to load all it's H::T template. Why not put
the code into H::T itself.
> - 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.
++++ - this would prevent a lot of ugly looking templates that I've been guilty
of making.
> - 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.
Again, I'm ambivalent.
> - 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... :-) ]
Would this just apply to tmpl_include or to all vars? If everything, then it
would need a 2 pass parser right? That would be pretty painful performance wise.
--
Michael Peters
Developer
Plus Three, LP
-------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/html-template-users
