Am 29.05.2012 17:26, schrieb Damon Courtney: > ## If you don't mind creating a variable in the request namespace > autogen_[incr ::request::__formElemCount] > > OR > > autogen_[info cmdcount] > > OR > > autogen_[clock microseconds] > > would all work just fine without the requirement of another package.
Hi Damon, Refering to the issue to generate the value "idcur" of: <label ref="idcur">labeltext</label><option id="idcur" name="namecur" value="valuecur"/> I have another thought on your propositions how to replace the uuid package. There are some solutions to generate the value "idcur": S1) uuid package S2) counter which starts with 1 at each http request S3) [info cmdcount] S4) [clock microseconds] S5) interpreter wide counter S6) form name + form internal counter Here are some thoughts: T1) The id must be unique per http request result T2) when requesting the same url, there should be the same answer. T3) Two http requests should not be in any information relation. T4) Don't expose any internals I am not shure about T3, but this feels as a potential security hole. Here is the judgement of the solutions and the thoughts: | T1 | T2 | T3 | T3 | ---+----------+----------+----------+----------+ S1 | yes | no | yes | yes | S2 | yes | yes | yes | yes | S3 | yes | no | no | no | S4 | no | no | no | no | S5 | yes | no | no | no | S6 | yes | yes | yes | no | So, S2 fullfills all thoughts. S3 to S5 would give internal information of the interpreter to the outside and put multiple requests in a relation (which request follows which). As stated before, I am not shure if this is an issue but it feels like a security hole. I prefer S6, as: + it is easiest to implement (object variable) + it is most logic to the outside - it exposes the internal form name (so T3 fails). Someone might have a better idea here. The form name may not be in the character set of an id. Enjoy, Harald --------------------------------------------------------------------- To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
