You are viewing a plain text version of this content. The canonical link for it is here.
Posted to rivet-dev@tcl.apache.org by Clif Flynt <cl...@cflynt.com> on 2010/10/28 01:03:48 UTC
form.tcl -method get|post?
Hi,
I'm using rivet 2.0.1.
The form package docco says:
-method ?post|get?
The http method for sending the form data back to the server. Possible
values are get or post
Note
At the time of writing only the 'get' method is implemented
My test indicates that putting "-method post" results in a 'get'
operation.
Is this likely to be updated/modified? Is there a variant of
form.tcl (cvs tip?) that supports post?
I grabbed the CVS tip of Tcl8.6 (yeah, living on the edge) in order
to get the newest tdbc. For reasons unobvious to me, the itcl that
builds out of the box doesn't quite support pure itcl syntax. In
particular, it requires a "[self] methodName" to invoke internal object
methods from within a method.
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?
I'm not sure that my kludge has long term use, though it might
provide a start on a port from itcl to TclOO.
Thanks,
Clif
--
... Clif Flynt ... http://www.cwflynt.com ... clif@cflynt.com ...
.. 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/ ............
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: form.tcl -method get|post?
Posted by Massimo Manghi <ma...@unipr.it>.
On 10/28/2010 05:17 AM, Karl Lehenbauer wrote:
> If the request is simply to weigh in, then I've got some rhymes for the house.
>
> Regarding the supposed Itcl compatibility of Tcl 8.6, having to invoke methods in the same object with either $this or [self] is a non-starter for us (FlightAware) -- we have way too much Itcl code for that plus it just smells. Surely it's temporary.
>
> Object systems let you build bigger programs without losing control of them. I think it's a really natural idea -- code and data are defined together and you can have multiple instances of something with all the data for each instance nicely grouped and easily accessed. Upvar is heavily (ab)used as a sort of pseudo-object system. Look at tcllib for lots of examples. For example with the http package, code accesses instances of data using upvar. It works but it's better to support it in a first order and non-kludgey way, i.e. built into the language.
>
>
I hope I'm not getting it wrong, but it seemed to me that the problem
Clif is struggling with is the lack of support in TclOO for marshaling
functions of public member variables. In that specific case I can make
out a common situation: handling together a list of <attribute> <value>
pairs that wouldn't be sensible to take apart as they are meant to end
up in the same tag. Before 8.5 (and 'dict') I extensively used the
constructs "array set ..." "array get ..." (at the cost of having
not-so-efficient code) to pass around lists that are thus guaranteed to
have even length and keep the association <attr>-<value>. I even ended
up writing an Itcl class around an array that enabled me to add some
extra features to the parameters processing of a form.
I agree that the 'upvar' abuse as a way of having pseudo-objects should
be avoided but in the specific case quoted by Clif we could get around
it changing the interface and changing the container from an array to a
dictionary
-- Massimo
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: form.tcl -method get|post?
Posted by Karl Lehenbauer <ka...@gmail.com>.
If the request is simply to weigh in, then I've got some rhymes for the house.
Regarding the supposed Itcl compatibility of Tcl 8.6, having to invoke methods in the same object with either $this or [self] is a non-starter for us (FlightAware) -- we have way too much Itcl code for that plus it just smells. Surely it's temporary.
Object systems let you build bigger programs without losing control of them. I think it's a really natural idea -- code and data are defined together and you can have multiple instances of something with all the data for each instance nicely grouped and easily accessed. Upvar is heavily (ab)used as a sort of pseudo-object system. Look at tcllib for lots of examples. For example with the http package, code accesses instances of data using upvar. It works but it's better to support it in a first order and non-kludgey way, i.e. built into the language.
I think object-oriented typeless langauges (like Itcl, etc) work well. You don't have to write different methods for all the possible datatypes like you do for C++ or Objective C.
I know form can do GET and POST.
On Oct 27, 2010, at 8:34 PM, 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
>
> 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 ... clif@cflynt.com ...
>> .. 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: rivet-dev-unsubscribe@tcl.apache.org
>> For additional commands, e-mail: rivet-dev-help@tcl.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
> For additional commands, e-mail: rivet-dev-help@tcl.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: form.tcl -method get|post?
Posted by Massimo Manghi <ma...@unipr.it>.
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: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: form.tcl -method get|post?
Posted by Damon Courtney <da...@tclhome.com>.
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 ... clif@cflynt.com ...
> .. 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: rivet-dev-unsubscribe@tcl.apache.org
> For additional commands, e-mail: rivet-dev-help@tcl.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: form.tcl -method get|post?
Posted by Clif Flynt <cl...@cflynt.com>.
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 ... clif@cflynt.com ...
.. 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/ ............
Re: form.tcl -method get|post?
Posted by Massimo Manghi <ma...@unipr.it>.
On Wed, 27 Oct 2010 19:03:48 -0400, Clif Flynt wrote
> Hi,
> I'm using rivet 2.0.1.
>
> The form package docco says:
>
> -method ?post|get?
>
> The http method for sending the form data back to the server. Possible
> values are get or post
>
> Note
> At the time of writing only the 'get' method is implemented
>
> My test indicates that putting "-method post" results in a 'get'
> operation.
>
> Is this likely to be updated/modified? Is there a variant of
> form.tcl (cvs tip?) that supports post?
the information in the manual is wrong and it's been corrected in the just
released Rivet 2.0.2 (how timely!)
>
> I grabbed the CVS tip of Tcl8.6 (yeah, living on the edge) in order
> to get the newest tdbc. For reasons unobvious to me, the itcl that
> builds out of the box doesn't quite support pure itcl syntax. In
> particular, it requires a "[self] methodName" to invoke internal object
> methods from within a method.
>
wouldn't '$this methodName' work out a solution?
> 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'm not sure that my kludge has long term use, though it might
> provide a start on a port from itcl to TclOO.
>
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.
-- Massimo
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org