metacard for CGI

andu undo at cloud9.net
Wed Mar 6 15:33:01 EST 2002


Mark Luetzelschwab wrote:
> 
> >Andu wrote:
> -the main disadvantage you see in using metatalk/rev for CGI scripting
> *besides some difficulty with debugging*
> 
> As someone who took a look at MC and decided to go with ASP..here are
> some things that I would really miss if I went back to MC (in the
> order of importance). Everything that I mention can (is) be done
> using cmc.exe - but its a pain.
> 
> 1. Request.Form / Request.QueryString
>         These allow me to grab the form data by name and any items in
> the query string.  No parsing necessary.
> 
>         Possible Syntax:
>                 http://www.metacard.com?userid=10101
>                 Request_QueryString("user_id") would return 10101
> 
>                 Similarly, if you posted the data instead of putting
> it in the URL..
>                 Request_Form("user_id") would return 10101
> 
> If these got separated far, far away from the read from stdin, you
> could write a debugger far, far easier by simply simulating the input
> and output.
> 
> 2. Server Variables
>         Is it a POST, GET, who from..
> 
>         Possible Syntax:
>                 Request_ServerVariables("REQUEST_METHOD")
> 
> 3. Session Variables
>         Not really necessary if MC is acting as a server to other MC
> clients, but very necessary for any kind of web applications that
> have more than one page -- using hidden form elements is the other
> option, but a pain.  Session variables stay alive between pages - but
> are only available to the person who started the session.
> 
>         Possible Syntax:
>                 Session_Set("variable_name",10101)
>                 put Session_Get("variable_name") would return 10101
> 
> 4. ODBC
>         Sure, MC can be a decent database - but its really nice to be
> able to do the database connections.  All I really need is a
> connection, a way to execute queries, and a table of the outputs.
> Simple enough ;)
> 
> 4. XML support, though I'm still whacking away at an xml_lib, so that
> might be a non-issue.
> 
> Hope this helps.

Thanks.

All good points with few exceptions. Not to forget that ASP, PHP were
created exclusively for web use and being able to run as modules to the
server gives them some of the advantages you mention above. I'm more
familiar with PHP which indeed has a whole bunch of built in functions
that would require, at best, many lines of code in Metacard to achieve
the same results.
As usual, the key to adding more functionality (and popularity) to
Metacard cgis is to have a significant number of people request those
features which make ASP and PHP the better choice besides the language
itself. Most important is probably a Metacard module for the main web
servers.

> 
> -ml
> 
> --
> _______________________________________________
> metacard mailing list
> metacard at lists.runrev.com
> http://lists.runrev.com/mailman/listinfo/metacard

-- 
____________________
Regards, Andu Novac



More information about the metacard mailing list