On 10/28/2010 03:34 AM, Damon Courtney wrote:
Just jumping in here. I'm working pretty heavily in Rivet for the next few
months, so I will be updating little things and making changes a lot. The form
package is due for some updating and a bit of an overhaul, I think. I know
that Karl said they have a version that returns the form elements instead of
outputting them, and that's probably a good change.
As far as I know, passing -method should accept anything. There's not an
actual check on what is supported, and what is supported in the form tag is up
to your browser. I know I ran into this recently. I would do something like:
form #auto -method PUT
I repeat myself: Clif was tricked into believing that POST wasn't
supported by a wrong note I added to the manual. In the hurry of writing
a manual page for form.tcl before releasing 2.0.1 I thought the GET
method was hardcoded (I must have been tricked into it while skimming
through the code). Shortly after I released Rivet I came round about the
implausible fact that method needed a specific support, since it's
simply an attribute of the <form ..> tag and belatedly amended the
manual. The manual in 2.0.2 is correct about it. Sorry for that.
I think all of our packages should be converted to TclOO if we can. Though the
latest Itcl IS built on top of TclOO, so we're really just talking syntax here.
I don't particularly care as long as we're talking TclOO in the future. I'm
all for moving things forward to 8.6 with a newer version. Not necessarily
dropping support for 8.5, just using 8.6 where we can. That would be one
advantage to using Itcl syntax. It remains backward compatible with 8.5 and
the old Itcl.
Anyone else wanna' weigh in here? 0-]
D
Do you think we should also consider as an option dropping the 8.5
support e move to 8.6? I mean, so much stuff is coming down the 8.6 pipe
that can be a plus to definitely place future releases of Rivet in the
new territory.
-- Massimo
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
