The reasons why I personally like the idea of Tcl procs for simple queries is the same as why I like reusability in general, i.e., less coding and increased maintainability. I fail to see how maintaining one Tcl proc and its associated common .xql file (or separate PG and Oracle *.xql files) can be more work than maintaining any number of clones of the same *.xql file(s) in all places they occur within a package (say) ...
Having said that, I am certainly not promoting the use of a Tcl API which calls something like "forum::get" in a foreach loop - those fields should, of course, be retreived from a separate query. OTOH, just because the previous is true doesn't mean "forum::get" has no use ... it might be useful in other places.
Also, we have a mechanism called the query dispatcher for a reason; the ability to support multiple dbs. Let's not go out and tell people that it's fine to skip this mechanism just because it's possible to do without it, or at least bypass it (by writing the queries inline). Let's instead encourage people to uniformly adhere to the standards we have once set out to follow!
As has been said elsewhere; we need fewer ways to achieve common tasks in this toolkit, not more ... What we need more of, though, is coding *standards* - not something vague like "best practices"!! This is how we lower the learning curve, by telling people explicitly how things are done.
What's most convenient/easy for an experienced OACS developer ought to also be easiest for a newbie, no?
/Ola
