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
And in viewing the source, it would say method="PUT", but when it was submitted
back to the server, PUT had been turned to POST (POST is the default, by the
way). After some reading, I think this was the browser doing it. I couldn't
find a better explanation. So, I was trying to figure out how the Rails guys
do it since they use PUT and DELETE as methods in their RESTful interfaces.
Turns out they fake it. They just include a hidden field that passes the
method, and the Rails code on the backend knows to look for this variable and
set the method to that. So, I went with that. 0-]
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
On Oct 27, 2010, at 7:16 PM, Clif Flynt wrote:
> On Thu, Oct 28, 2010 at 12:38:29AM +0100, Massimo Manghi wrote:
>>
>> wouldn't '$this methodName' work out a solution?
>
> I won't swear to it, but I think I tried that first, and 'my cmd',
> and neither of them was happy with me.
>
>>> I've got a kludged version of form.tcl that works (to the extent
>>> that I've tested it) with the new 8.6.
>>>
>>> Is anyone interested in this code?
>>>
>>
>> yes, I am.
>
> I've attached it to this email. If attachments get scrubbed, let
> me know, and I'll mail it direct.
>
>> It's something we should talk about. Tcl 8.6 is getting momentum among the
>> Tcl'ers and its new introductions will probably set new standards in the
>> language history.
>
> I'm pretty bullish on TclOO. I think it's a nice mix of providing
> structure while still giving the developer the freedom to rework
> things as his understanding of the problem matures. (How's that for
> buzz-word compliance?)
>
> I worked in C++ for 5 or 6 years and did a little with itcl. I ended
> up unthrilled with OO. TclOO has revived my excitement.
>
> This construct in the form.tcl code was the only one that caused
> me some dismay at a quick-N-dirty translation to TclOO:
>
> public variable defaults "" {
> upvar 1 $defaults array
> array set DefaultValues [array get array]
> }
>
> I think this can be implemented in TclOO with a variable trace and a
> new object method, but I didn't have time right then to play with it.
>
> Clif
>
> --
> ... Clif Flynt ... http://www.cwflynt.com ... [email protected] ...
> .. Tcl/Tk: A Developer's Guide (2nd edition) - Morgan Kauffman ..
> .. 17'th Annual Tcl/Tk Conference: 2010, Oak Brook, IL USA ..
> ............. http://www.tcl.tk/community/tcl2010/ ............
>
>
>
>
>
> <form8.6.tcl>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
