Can you elaborate on this a little bit? I don't see where the problem
would lie. My thinking is that it's different from a .tmpl file.
Basically, once you can write template code, the potential for being able to co-opt a site is very, very high. Template code == Database access with the right plugin. I don't think Slash tries to prevent against that. Plus, it's very easy for a template to perform one query too many and drive down site performance. If this is done for -every story view-, you might be a long time in finding the problem.
Of course, I'm being paranoid and extremist in my examples, but rather prepare you for the worst rather than hand you a pair of rose-colored glasses and have everything fall apart.
The one obstacle I could see is the pre-rendering of the stories.
Slashd writes them to disk as .shtml's, so there'd be no question,
it'd just ignore the template toolkit code within the story.introtext
For .shtmls, yes. This might be true, however that's ONLY if you are planning on using templates-in-stories for anonymous vs logged in content. If you have bigger things in mind, even .shtml generation might bring up some issues.
But when a user hits articles.pl does it show pre-rendered (from
cache) or render it right then and there? If right then and there, it
would seem the template running would be no different from a .tmpl
and it'd be limited to the current user.
I'm not quite up-to-speed on the entire pre-rendering mechanism, but I *think* the pre-rendered form is shown in normal site operation for logged in users. This might cause problems for non-saavy users who are expecting more dynamic content from the implication of templates-in-stories.
Obviously, you'd have to fully trust your site admins (ie authors)
with writing template toolkit code. That in itself is kinda scary.
And that's pretty much what I was referring to. Remember, if you include the ability to write templates in stories, a bad apple need only break
into the *site* to potentially damage the entire server. For someone to abuse .tmpl files, they'd have to break into the *server*, which while
also doable is a bit more difficult.
It basically all boils down to a matter of trust.
And having admins write (potentially bad) template code can make debugging
site problems two to three times as hard. Even innocent stuff like missing "-%>" can cause really wacky things to happen and it's not like
the site admin can browse the error logs to find out the problem.
All in all, I see less gains than issues with doing such things without a lot of learning curve, proper training, and huge amounts of trust before something would be gained by such a thing. Not saying it might not be a worthwhile addition to a sight run by a tight core group of editors (which is why I included a way it *might* work in my original missive), but that it might not be something that only the saaviest of Slashcode site admins need consider.