At this stage I don't intend it to replace Template.__init__ like your example
suggests. I think we should maintain that for backwards compat. What I'm
suggesting would be an alternate approach and eventually the preferred
approach, if it works.
I never planned on rewriting the caching mechanism. Rather I wanted to make it
more extensible. No promises ...
On Wednesday 18 May 2005 17:18, mso@... wrote:
> Tavis wrote:
> > see the attachment for a rudimentary implementation of this. Does it
> > work for
> > you and what do you think of the concept/implementation?
> I ran the script and it printed a vertical row of numbers from 0-9. So
> users would normally do:
> from Cheetah.Template import Template
> t = Template(file="filename")(searchList..., otherArgs...)
> That will take some getting used to, but if it normalizes Cheetah's
> handling of classes it's prob'ly worth it.
> Does this take us closer to isolating precompiled templates from changes
> in Cheetah versions, or make it easier to add features to Cheetah without
> breaking precompiled templates? That woud be desirable. I'm not sure
> that the user's template instance should have to inherit from Template
> (and thus Servlet), or whether it could just contain it. Likewise, we may
> be able to hide from templates the specific way valueFromSearchList is
> called if templates instead call a wrapper method that assembles the
> arguments behind the scenes.
> I wouldn't mind a move to Cheetah 2.0 with incompatibilities for
> precompied templates (or even template definitions), if it allowed
> streamlining the code and documentation. I'm surprised Cheetah is so
> reliable considering how complex it is (a tip o' the hat to the
> implementor), but the minimalist in me wishes it were simpler and didn't
> have a 87-page manual. I wish the manual didn't need elaborate caveats
> for #extends, #extends vs #implements, why using $ is good (except when
> it's bad), and telling non-Webware users to just ignore the Webwareisms in
> the core.
> One high priority would be using new-style classes throughout, now that
> they are stable. It would also allow us to standardize on a newer version
> of Python. (We tried to keep Cheetah compatible with Python 2.0 for a
> long time although we finally discovered a few months ago some
> incompatibilties had crept in.)
> On, and what's up with caching? You've been saying for three years you'd
> do a major rewrite of the caching system someday. Is caching really
> needed now or can we perhaps drop it? It seems to be less useful for
> Webware than we anticipated, considering Webware's servlet caching seems
> to do a more appropriate job. How many people are using caching? Of
> those, how many would get significant inefficiency if it disappeared?
> This SF.Net email is sponsored by Oracle Space Sweepstakes
> Want to be the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
> Cheetahtemplate-discuss mailing list