Revision 35 (by (no author), 2000/08/10 14:43:08) This commit was manufactured by cvs2svn to create tag 'beta-2'.
#------------------------------------------------------------------------
# KNOWN BUGS AND/OR LIMITATIONS
#------------------------------------------------------------------------

* Template process($file) method returns a string if the named
  template ($file) can't be found, rather than an exception.  This
  should be changed so that an exception is returned whatever?

* It's currently not possible to catch a 'perl' exception because 'PERL'
  is a reserved word.  You need to enable the CASE option to be able to 
  make a distinction between them.  THROW and CATCH should accept quoted
  exception names to prevent these kind of issues.

* Filters and plugins cache may bloat.  Perhaps reset() should accept
  flags to clear BLOCKS, PLUGINS, FILTERS, etc.  I need to check this.

* The 'ttree' script doesn't yet have knowledge of all the new 
  configuration items.

* There's no easy way to run version 1 and version 2 on the same
  machine.  If you're happy to junk version 1 then no problem, go
  ahead.  If you want or need to keep version 1 then you can install
  one or the other under a separate directory tree, e.g.

    perl Makefile.PL PREFIX='/home/abw/tt1'

  You'll need to tell your scripts (and also tpage and ttree if you
  use them) where to find this version.  E.g.

    use lib qw( /home/abw/tt1 );

  I've been playing around with moving version 1 modules into
  Template::v1::* to allow them to co-exist.  I think this is nearly
  ready to roll out, but it still needs some polish and it's lowish
  priority at the moment.

* Note that no recursion checking is performed for BLOCKs, only 
  Template::Document instances.  This is probably the way it will stay
  (unless anyone shouts loudly enough) but it should be documented
  anyway.

* I've had a few reports of tests failing (provider.t test 37 and several
  in args.t) but haven't been able to reproduce them.  If you do get 
  any errors, please run the test individually (e.g. 'perl t/provider.t') 
  or 'make test' in verbose mode (e.g. 'make test TEST_VERBOSE=1') and 
  send me the output, along with any other relevant information.  If you're
  able to track down the problem then so much the better.  The test suite
  is well organised and fairly pleasant to work with these days so please
  don't be afraid to go digging for answers.

* The XML::RSS plugin test may generate warnings (but passes all tests)
  under Perl 5.6


#------------------------------------------------------------------------
# PENDING ITEMS ON THE 'TO-DO' LIST
#------------------------------------------------------------------------

* I had a patch from someone to make 'print' work as expected in PERL
  blocks.  That must have slipped through the net.  Need to find it 
  and apply it.

* Finish and tidy up documentation.  At the moment, all (er, most?) of
  the individual modules should be fully documented.  Everything thing 
  else (or most of it) is bundled into the monolithic Template.pod.
  I should probably split this up.  Need to generate an HTML version.

* test and document 'component' variable

* fix _private and .private tests in t/object.t

* 'tpage' could do with a '--define var=value' variable and possibly 
  others.


#------------------------------------------------------------------------
# POSSIBLE FUTURE ENHANCEMENTS
#------------------------------------------------------------------------

* It would be useful if template components had some notion of inheritance
  so that a 'derived' component could call on the 'super' component.  
  This can probably best be acheived by means of a Template::Component
  object, derived from Template::Document, which has a super() method
  (and maybe many other magical methods).  The super() method would 
  return a reference to another "parent" template which could be processed
  by a directive of the form [% INCLUDE $component.super %]

* I've written a version of Template::Stash in XS which should give a 
  significant speedup to the runtime processing.  It's 95% complete and 
  just needs some minor debugging and testing.  The new Template::Stash
  will automatically load the existing Perl version if you don't have
  a C compiler on your platform (shame on you!)

* The core parser FSM loop could also be implemented in XS to bring
  some speeds-ups there.  Better still would be to rewrite the entire
  parser in C/YACC.  This is entirely feasible now that we only have
  to transform the input text (template) to output text (Perl) and
  don't have to build any significant Perl structure.  It's not
  entirely trivial - the scanner in particular has to handle CHOMP
  options and user-definable TAGS, but it's certainly possible.

* An alternate parser back end could generate code which bypasses the
  stash altogether, based on Doug Steinwand's strategy.  The V2
  generated Perl code is much faster than V1 but still falls short of
  what Doug has shown is possible.  His parser gets the massive
  speed-up by bypassing the stash altogether (which in V1 was
  particularly hideous) and directly generating code to walk the stash
  structure and do the right thing.  A little magic was lost, so for
  this version I've stuck with the full-blown stash approach which
  provides all the magic for backwards compatibility, albeit at some
  trade-off in speed.  Nevertheless, compiled V2 templates should
  easily run twice as fast as under V1.  My current idea is to
  hack the parser to generate more explicit stash navigation code
  which uses direct access where the type can be grokked in advanced
  (i.e. a NUMBER implies the parent is an ARRAY).  I'm also wondering
  if we could add the '->' operator as a clue to the parser to do
  direct access rather than stash access.  e.g.  
  
    [% something->first %] => $stash->{'something'}->{'first'} 
    [% something.first %]  => $stash->get('something', 0, 'first', 0)
  
  The second example is as per the current V2 beta and allows
  'something' to be either a hash with a 'first' member (which may be
  a sub-routine which is then called), or an object with a 'first'
  method, or a list from which the first item is returned, etc., etc.
  All magic is intact.  The first example runs much faster and in
  those cases when you know you haven't got any magical variables,
  this is a Good Thing.  Doug used a combination of -> and () to give
  enough clues to Do The Right Thing most of the time, so I'm hoping
  that we will be able to incorporate some of those ideas some time
  soon.

* A 'FOR', like 'FOREACH' but without using an iterator.  You wouldn't get 
  the 'loop' reference to test 'first', 'last', etc., against, but it would
  be faster for those cases when you didn't need that.


#------------------------------------------------------------------------
# MISCELLANEOUS
#------------------------------------------------------------------------

* Jonas reported that 'e' is no longer an alias for 'error' in CATCH 
  blocks, but it is.  Need to check with him about that.

* should the CASE option be set by default to avoid variable conflict?
  If it was then it would allow directives such as 'FORNEXT' to be 
  the preferred 'NEXT' without risk of conflict with a 'next' variable
  (which I for one tend to use an awful lot)

* Add :preload use option to Template.pm to preload all modules?  Or should
  it be :noload and have preload by default?  Or should it not bother?

* Note that v1 \refs are not supported.  I don't know if they ever should
  be, but I think that some of the problems for which refs were conceived
  are still valid.  Hmm, maybe not.

* change all hardcoded object isa tests to use $Template::Config:XXXXX
  e.g. if (UNIVERSAL::isa($foo, $Template::Config::CONTEXT)).  Dunno if
  this is still relevant.  Need to check.

* merge Directive into Parse.yp via template process?  Yeah, one of these
  days RSN.