Re: [AOLSERVER] Input data verification

2002-11-04 Thread Scott Goodwin
Hi Daniël,

Yes, this would be useful, maybe as a standard ns_* style command,
something like an ns_bind_vars.

Right now the focus is on setting up a core AOLserver team, getting
AOLserver 3.5.0 fully documented, getting the current modules cleaned
up/documented, getting AOLserver 4.0 released, and a few other things.
When the majority of that work is done, I think we can look at
improvements to the server and modules such as you've outlined below.

How are your C skills? Your man page creation skills? That’s where we
could use some help right now.


/s.



-Original Message-
From: AOLserver Discussion [mailto:AOLSERVER@;LISTSERV.AOL.COM] On Behalf
Of Daniël Mantione
Sent: Monday, November 04, 2002 3:42 PM
To: [EMAIL PROTECTED]
Subject: [AOLSERVER] Input data verification


Hello,

You have propably all build a simple a html form and a
script that processes the form. Now how do you verify your input data?

For example, you want the user to enter a number. How do you verify on
the server side that someone indeed sent a number?

Usually I use the scan command, i.e.:

set r [ns_conn form]
set variabletxt [ns_set iget $r variable]
if {[scan %d $variabletxt variable] == 0} then {
ns_returnnotfound
return -code return
} else {
.
}

Now this is quite a lot of code for such a simple check and you write it
in each form again. I got a bit bored and wrote a library for it. Now it
is much easier, at the start of a script I just do:

bind_form_vars {mode req num} {actionurl req} {tabledef req} {index num}
{action}

What does this do?

- A form variable "mode" is assigned to the variable "mode". The
variable
  is required ("req") and it must be numeric ("num").
- The form variable "actionurl" is assign to the variable "actionurl"
and
  it is required.
- The same for "tabledef".
- "index" is not required, if it is not present the variable "index"
will
   be set to {}, but if it is present it should be numeric
- "action" is not required

Now, since it is a very basic task that allmost every AOLserver user has
to do, is it perhaps an idea to make such a library part of the standard
AOLserver distribution?

Daniël



Re: [AOLSERVER] Input data verification

2002-11-04 Thread Patrick Spence
why not the tcl command "string"

like:  string is integer $string

:)  http://tcl.activestate.com/man/tcl8.4/TclCmd/string.htm


--
  Patrick Spence 
  www.RandomRamblings.com
  www.Ariven.com

- Original Message -
From: "Daniël Mantione" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, November 04, 2002 2:41 PM
Subject: [AOLSERVER] Input data verification


> Hello,
>
> You have propably all build a simple a html form and a
> script that processes the form. Now how do you verify your input data?
>
> For example, you want the user to enter a number. How do you verify on the
> server side that someone indeed sent a number?
>
> Usually I use the scan command, i.e.:
>
> set r [ns_conn form]
> set variabletxt [ns_set iget $r variable]
> if {[scan %d $variabletxt variable] == 0} then {
> ns_returnnotfound
> return -code return
> } else {
> .
> }
>
> Now this is quite a lot of code for such a simple check and you write it
> in each form again. I got a bit bored and wrote a library for it. Now it
> is much easier, at the start of a script I just do:
>
> bind_form_vars {mode req num} {actionurl req} {tabledef req} {index num}
{action}
>
> What does this do?
>
> - A form variable "mode" is assigned to the variable "mode". The variable
>   is required ("req") and it must be numeric ("num").
> - The form variable "actionurl" is assign to the variable "actionurl" and
>   it is required.
> - The same for "tabledef".
> - "index" is not required, if it is not present the variable "index" will
>be set to {}, but if it is present it should be numeric
> - "action" is not required
>
> Now, since it is a very basic task that allmost every AOLserver user has
> to do, is it perhaps an idea to make such a library part of the standard
> AOLserver distribution?
>
> Daniël



[AOLSERVER] Input data verification

2002-11-04 Thread Daniël Mantione
Hello,

You have propably all build a simple a html form and a
script that processes the form. Now how do you verify your input data?

For example, you want the user to enter a number. How do you verify on the
server side that someone indeed sent a number?

Usually I use the scan command, i.e.:

set r [ns_conn form]
set variabletxt [ns_set iget $r variable]
if {[scan %d $variabletxt variable] == 0} then {
ns_returnnotfound
return -code return
} else {
.
}

Now this is quite a lot of code for such a simple check and you write it
in each form again. I got a bit bored and wrote a library for it. Now it
is much easier, at the start of a script I just do:

bind_form_vars {mode req num} {actionurl req} {tabledef req} {index num} {action}

What does this do?

- A form variable "mode" is assigned to the variable "mode". The variable
  is required ("req") and it must be numeric ("num").
- The form variable "actionurl" is assign to the variable "actionurl" and
  it is required.
- The same for "tabledef".
- "index" is not required, if it is not present the variable "index" will
   be set to {}, but if it is present it should be numeric
- "action" is not required

Now, since it is a very basic task that allmost every AOLserver user has
to do, is it perhaps an idea to make such a library part of the standard
AOLserver distribution?

Daniël



[AOLSERVER] Googling the AOLserver Documentation

2002-11-04 Thread Jerry Asher
Peter M. Jansson writes:


On Sunday, November 3, 2002, at 02:33 PM, Scott Goodwin wrote:


Documenting multiple commands on the same page ... will confuse the
readers


I disagree; I find, for example, that the traditional AOLserver
documentation including all variants of ns_return on a single page helps
me to better understand the range of responses available.


Yes, I absolutely agree with this.  When inspecting APIs, I always first
want to know, what is the range of possibilities.  I don't get that answer
when the responses are listed only on separate pages.

I suspect too that listing these things on the same page will help us Google
the manual.  I no longer bookmark the doc pages for Tcl or AOLserver, I
google the command and hit the lucky button.  That's a pretty wonderful
thing to be able to do.


Jerry



[AOLSERVER] Call for AOLserver Core Team Nominees

2002-11-04 Thread Nathan Folkman
We would like to establish an AOLserver core team made up of members from both here at AOL and the Open Source Community. The core team's main responsibility will be to lead the future direction of the AOLserver Open Source project, working to balance the internal requirements here at AOL with the requirements of the community at large. 

We've decided to adopt the core team principles currently in use by the Tcl core team - it seems to have worked well for them, and seems to also be a good fit for the AOLserver project. There will probably be a few slight modifications made, but essentially the core team will function as described by the following:

http://www.scriptics.com/cgi-bin/tct/tip/0.html

If you are interested in becoming a member of the AOLserver core team, please send me ([EMAIL PROTECTED]) an email with a brief paragraph or two describing your qualifications, and why you think you would be a good candidate. We will then post the names and descriptions and allow everyone to vote for the top three.

Please let me know if there are any questions. Thanks!

- Nathan


Re: [AOLSERVER] Sign Up for AOLserver Documentation!

2002-11-04 Thread Nathan Folkman

In a message dated 11/3/02 10:49:42 PM, [EMAIL PROTECTED] writes:



What was the new chat time on Thursdays? Last stated was 3pm Eastern, but then you asked for any takers at 2pm Eastern. I abstained, and no one else spoke up, so I'm assuming it was finally changed to 3pm Eastern.

  

 I intend to hang out in the chat room all day from now on.

  

 /s.



i'll have to look back at my notes. i think it was 3est.


Re: [AOLSERVER] AOLserver command style guide (was Re: [AOLSERVER] Sign Up for AOLserver Documentation!)

2002-11-04 Thread Zoran Vasiljevic
On Monday 04 November 2002 12:58, you wrote:
> > Is there some reason not to rename the 'nsv_*' commands to correspond to
> > Tcl's 'array' command?  Thus, 'nsv_set' would change to 'ns_array set',
> > so that
> >
> >   ns_array set
> >
> > would correspond to Tcl's
> >
> >   array set
> >
> > and so on.
>
> Again, to remain idiomatic, I think:
>
> nsv_set arrayName elementName value => nsv set arrayName elementName value
> nsv_get arrayName elementName => nsv get arrayName elementName
> [...]
> nsv_array names arrayName => nsv array names arrayName
>

I've reimplemented (and significantly extened) nsv_*
for the Tcl threading extension 2.4 by using Tcl_Obj*
for internal storage. There, I've used tsv::*

  tsv::set arrayName elementName value
  tsv::incr arrayName elementName ?increment?

  etc...

The "tsv" stands for "thread shared variable"
This is another possibility, since AOLserver
has dumped the pre8 Tcl version.

Zoran



[AOLSERVER] AOLserver command style guide (was Re: [AOLSERVER] Sign Up for AOLserver Documentation!)

2002-11-04 Thread Dossy
On 2002.11.03, Scott Goodwin <[EMAIL PROTECTED]> wrote:
> I Agree. We'll do the 3.5 docs first as-is. I think at some point we
> should bite the bullet and rename commands like
>
>ns_returnadminnotice
>
> to be
>
>ns_return adminnotice
>
> and maintain that consistency throughout the server and modules.
> Backward compatibility would be kept for some period of time.

Agreed.  This is Tcl's idiomatic way of doing things, which I think
would be good to remain consistent within AOLserver.

> Is there some reason not to rename the 'nsv_*' commands to correspond to
> Tcl's 'array' command?  Thus, 'nsv_set' would change to 'ns_array set',
> so that
>
>   ns_array set
>
> would correspond to Tcl's
>
>   array set
>
> and so on.

Again, to remain idiomatic, I think:

nsv_set arrayName elementName value => nsv set arrayName elementName value
nsv_get arrayName elementName => nsv get arrayName elementName
[...]
nsv_array names arrayName => nsv array names arrayName

That's just my two cents, of course.

-- Dossy

--
Dossy Shiobara   mail: [EMAIL PROTECTED]
Panoptic Computer Network web: http://www.panoptic.com/
  "He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on." (p. 70)