ACCEPT fieldname FROM POST “fieldname”.
Last Updated on Thursday, 11 November 2010 12:20 Written by aoirthoir Thursday, 11 November 2010 12:08
Currently to access GETS and POSTS from a web form in OpenCOBOL is a bit of a process. With gets we have to read the query_string and with posts we have to read from keyboard. Then we have to URL-DECODE the entire thing. Finally we have to unstring, or search the entire read, and separate it out, field by field.
JCurrey and team at Currey Adkins have a wonderful product to assist in this and I love what they’ve done. At some future date I will be making a post about it. In the meantime I want to toss out an idea for Roger and the others helping him with the OpenCOBOL compiler.
We’re able currently with OC to do the following:
ACCEPT query_string FROM ENVIRONMENT "query_string".
MOVE "somevalue" TO some-literal.
ACCEPT somefield FROM ENVIRONMENT some-literal.
Essentially we’re able to accept a value from the environment into a variable. It’s fantastic and wonderful in it’s simplicity. What I would like to see is more direct web integration in the OpenCOBOL compiler. Imagine for a moment the beauty of being able to do something like:
ACCEPT first-name FROM POST "first-name".
ACCEPT search-value FROM GET "q".
ACCEPT inventory-item(count) FROM POST "inventory-item" (count).
And other such things.
The compiler would have to have inbuilt the ability to read the query_string (for GETS), url-decode them, and then process them into separate variables. For the POST variables it would have to read from the keyboard, url-decode and then convert to specific variables. For the COBOLer though, this would simplify their ability to interact with web forms.
Thoughts?
This content is published under the Attribution-Share Alike 3.0 Unported license.
I love the idea. If the interface is based on json then there are plenty of json utilities in js send and/receive json format data.
It would need to allow JSON or not. HTML forms don’t need json themselves. JSON is an additive. If you do a submit from a form, javascript itself typically is not involved.
So it needs to handle both.
Aoirthoir, my inclination would be to prefer to use user defined functions.
The compiler would remain standard that way.
All of our work with CGIgnite is in COBOL, so we know that our clever developer community could write the functionality you want without resorting to bringing in another language.
We are not opposed to JS or other languages, but would prefer to stay away from add-ons when OpenCOBOL can do the job.
Either way, I think your idea is a great one!
I guess I need to keep working on that json utility then. sigh.
Anyway OC 2.0 will make these sort of things much more meaningful and do-able. WHERE IS MY OC2!!!!???
William posted on OCO and this is my response…
[quote]
wmklein wrote:
It seems to me that rather than this extension, what you may want to look at is the two existing XML support features
1) The ISO TR on this. (Micro Focus already supports something similar to this) See:
[url=http://www.cobolstandard.info/j4/files/07-0005.doc]http://www.cobolstandard.info/j4/files/07-0005.doc[/url]
2) The IBM “XML GNERATE/PARSE” statements, see;
[url=http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/IGY3PG50/5.1 ]http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/IGY3PG50/5.1 [/url]
* * * *
I know that getting HTML input is NOT the same thing as parging/generating XML, but I think the similarities are such that using one of these two featurs could be extended to do what you are thinking about[/quote]
I would have to dig into them a bit to see. However, the way XML day is formatted is fairly different from what we get in a query_string (for gets) or READ FROM KEYBOARD (for posts).
The pattern in each of these is:
var=someval&var2=someval&var3=someval etc. Of course some val could have values that need to be decoded using a URL-DECODE functionality. Basically replacing %## with its hex equivalent (I think). Thus %20 is a space.
Now this can be done already natively with OpenCOBOL fairly easily. A few unstrings, SUBSTITUTES. Jim Currey’s method of doing it is fairly nice, just a CALL. And that certainly works.
I am proposing this idea because really a post or a get is nothing more than an accept. Utilizing this methodology would bring OpenCOBOL more in line with other languages. It would also add more to “native” web capability. ACCEPT VAR FROM POST “var” seems really intuitive to me as well. It’s just natural. If someone wanted to make it more clear it could be FROM HTML-FORM-POST or WEB-POST or something. But I’ve a feeling that POST/GET would be just fine (would need to support both).
It might be interesting to allow User Defined ACCEPTS. Then the functionality could be entirely coded in OpenCOBOL.
Well I am all for UDF’s but we are still awaiting on OC2. That’s the crux of the matter.
A lot of extra coding is going into getting around these issues when we could create the UDF’s required and make a library from them. So the burning question is…. where and when is OC2?