On Fri, 11 May 2001, Valerio Gionco wrote:
> > I think David should also consider a function to return
> > QUERY_STRING in a name-value list (suitable for array set) - like
> > script.dtcl?a=b&c=d&e=f -> {a b c d e f}. That way it could be used to
> > fetch any data w/o involving sublists... Simple
> > 'foreach {n v} [hargs] { hputs "$n=$v<BR>\n" }' would do.
> This could be a good solution, too, if we don't care about replicating
> all variables in two places. (we must put values in VARS too, to
> keep compatibility with old scripts).
There are two problems with ANY replicating VARS:
1. memory
2. init time (I like dtcl because it's fast ;-)
That's why there should be commands for creating such arrays or getting
data from apreq. For sites with many older scripts, it might be useful to
put 'hgetdata' (or any other command name :-) in the BeforeScript. Newer
scripts could select how they want to access data somewhere in the
beginning.
Example - I don't need to have ENVS, VARS (, VARSL?) to do a headers
redirect based on only cookies. This may seem a bit useless for now, but
if/when dtcl will have more init code, it will be slower. That's one good
reason to think about it now, when there'll be less code to convert.
Do benchmarks on 'hello world' with html, dtcl, php and aolserver (maybe
also try cgi to have sth to laugh at ;-). Last time I checked aol was
fastest, then dtcl... It's a good position to maintain :-)
> > ps. I also vote for alias 'p' to 'hputs' in the core - to use <?p $var ?>
> > (a bit similar to AOL's <%=$var%> :-). I use it for 2 weeks
> > (proc p {args} {eval hputs $args} ;-) and it's great help. Also, since
> > stuff outside <? ?> is parsed to hputs "string", it could be put directly
> > in that hputs statement. And it would be wonderful is it could be shorted
> > to <?p$var?> - a bit obfuscated perhaps, but I like small code ;-).
> ....hmmmm...I see myself reading my own code within a year or so and
> asking "what the #Ł$%& are all those 'p' ????"....
I don't think so - <?p$var?> might be a bit strange, but
<?p[mk.html [var.get displaytext]?> is quite readable.
> Anyway the name-value list is a very comfortable solution. Since usually
> CGI variables are not so many, duplicating them shouldn't hurt too much.
It imho always hurts to do anything that's not needed - especially with
WWW where you often aim at getting most hits/day with your engine...
Trust me, I've seen people happy about gaining 1000microseconds/request
by static linking everything. It really counts on high-end solutions :-)
> Loking at the source code, I realize that the simpler thing to do would
> be simply adding a variable $::request::VARSL; thus the TCL code
> becomes
Easiest way out is not always the best one ;-)
--
Wojtek Kocjan
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
