Re: [Cheetahtemplate-discuss] Proposal: eliminate .addToSearchList and .prependToSearchList
- On Saturday 02 November 2002 02:53 am, Mike Orr wrote:
> The problem with .add/prependToSearchList is not that they don't work,ok, not sure i entirely follow you, so i'll just do as you say until i know
> it's that I don't like the idea of the searchList being mutable.
> you control the template instantiation, it seems like an unnecessary
> complication. If you don't control the instantiation, then it seems
> doubly important that you don't add/delete searchList objects, because
> then your changes leak into other portions of code you don't control,
> and that violates the principle of encapsulation.
what you mean. ;-) what do you mean me control, you control?
> I'm trying to prevent you from painting yourself in a corner as yourok, i think i'm following you there -- makes sense.
> application gets bigger and more complicated with dozens of templates,
> and it becomes difficult to keep track of which template instances have
> object A added/prepended at which points in the code, and which don't.
> That's the beauty of immutability. Like a tuple:
> (myDict, myInstance)
> you cannot add/delete elements from this tuple. But you can modify
> myDict and myInstance as much as you like. If we make the searchList
> immutable, there is *one* place you can quickly look -- the
> instantiation line -- to see exactly what the searchList contains. And
> you are guaranteed that it will never change (absent .append/.insert
> Actually, shall we just go all the way and make the searchList aare you saying, just to be really sure people don't use append/insert? sure,
> tuple in .__init__? Does Cheetah need to use list methods on it?
why not? I don't know, you guys are the smart ones. ;-)
> Thanks. Your questions help us see what needs to be explained bettercool how you kinda switched that around to thanking me for asking dumb
> in the docs and future FAQ. Also, when you describe your real-world
> situations and problems you have using Cheetah with them, it helps us
> see how Cheetah can be improved. We are always looking to add features
> that solve a general class of problem; that is, something a variety of
> users will want. You may not even realize it at the time, but it may
> turn out later that "your" problem was not just your esoteric
> situation, but a fundamental weakness in Cheetah that you were the first
> to discover.
questions. sometimes people can be too nice, you know!! :-)
> > i wishi used to not do irc, but then i started doing stuff that seemed to have a big
> > we had a #cheetah channel to get around the latency of the list
> I don't do IRC, but if you start a channel on irc.debian.org maybe
> you can convince others to participate. I prefer e-mail or the
> phone. E-mail because you can collect your thoughts and then have
> a message you can save in case it becomes useful later, and the
> phone because you can discuss in thirty seconds what it takes
> several minutes (and lots of carpal-inducing keystrokes) to type.
irc presence and a slight lack of adequate docs (ie, installing linux on
ipaqs) and i started to get into it. i still pretty much only pop in to ask a
question, but some people seem to live in irc. i usually hang out -- well,
pop into when i need help ;-) -- irc.openprojects.net, in #python, #gentoo,
etc... (i kinda switched from debian to gentoo a few months ago, on servers
This sf.net email is sponsored by: See the NEW Palm
Tungsten T handheld. Power & Color in a compact size!
Cheetahtemplate-discuss mailing list
- jamie@... writes:
> but what really makes me strange is that, to me, a template doesn'tYes, I agree. This is how I think of templates; templates should be
> (ie, if this is possible with Cheetah) define an entire page. it
> MIGHT, but not necessarily. a template might only define a tiny
> piece of a page and then get "embedded" in a larger template.
able to own each other.
> Some templates will produce some sort of dynamic content -- such asNot to me it doesn't ;)
> news headlines.. Originally I planned to separate "templates" that
> produce different sorts of content physically -- but then I realized
> that the distinction was logical. Ideally, I'd have different
> classes of templates -- for example, themes vs layout vs content
> producing, but inherently they still all should be able to extend
> each other in various ways. OK, that sounds really nuts [..]
mike [at] mike [dash] warren [dot] com
gpg --keyserver 220.127.116.11 --recv-key 579911BD
87F2 4D98 BDB0 0E90 EE2A 0CF9 1087 0884 5799 11BD
This sf.net email is sponsored by: Are you worried about
your web server security? Click here for a FREE Thawte
Apache SSL Guide and answer your Apache SSL security
Cheetahtemplate-discuss mailing list