Am 11.01.2006 um 19:06 schrieb Zoran Vasiljevic:
I'm looking into this now... I will suggest we change
this for *all* Tcl callbacks.
I'm about to checkin changes to various ns_schedule_* and ns_register_*
procs to allow variable number of arguments passed to scripts as
discussed here.
Here
No
Zoran Vasiljevic wrote:
Am 02.01.2006 um 13:31 schrieb Zoran Vasiljevic:
Am 31.12.2005 um 18:24 schrieb Vlad Seryakov:
Agreed on that as well, let's do it
Conclusion:
ns_register_filter when method urlPattern script ?arg1 arg2 ...?"
The script definition must thus match:
proc sc
Am 02.01.2006 um 13:31 schrieb Zoran Vasiljevic:
Am 31.12.2005 um 18:24 schrieb Vlad Seryakov:
Agreed on that as well, let's do it
Conclusion:
ns_register_filter when method urlPattern script ?arg1 arg2 ...?"
The script definition must thus match:
proc script {when args} {...}
For cal
Am 31.12.2005 um 18:24 schrieb Vlad Seryakov:
Agreed on that as well, let's do it
Conclusion:
ns_register_filter when method urlPattern script ?arg1 arg2 ...?"
The script definition must thus match:
proc script {when args} {...}
For calls w/o args, we are compatbile with AS.
For calls w/
Agreed on that as well, let's do it
Stephen Deasey wrote:
On 12/31/05, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote:
Am 31.12.2005 um 01:15 schrieb Gustaf Neumann:
Class Filter
Filter instproc preauth args { }
Filter instproc postauth args { }
Damn, you are right. In which case w
Am 31.12.2005 um 12:54 schrieb Stephen Deasey:
The order:
TheFilter preauth arg1 arg2
makes the most sense to me. The is not an optional arg, it's
always appended. Required args always come before optional args in
proc specs...
Allright.
If we changed this, we should also change Ns
On 12/31/05, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote:
>
> Am 31.12.2005 um 01:15 schrieb Gustaf Neumann:
>
> >
> > Class Filter
> > Filter instproc preauth args { }
> > Filter instproc postauth args { }
> >
>
> Damn, you are right. In which case we'd do:
>
> ns_register_filter
Am 31.12.2005 um 01:15 schrieb Gustaf Neumann:
Class Filter
Filter instproc preauth args { }
Filter instproc postauth args { }
Damn, you are right. In which case we'd do:
ns_register_filter GET /junk myfilter myarg1 myarg2 ...
and it would call the filter as:
myfilte
Zoran Vasiljevic wrote:
Am 30.12.2005 um 19:19 schrieb Gustaf Neumann:
how will be the call, when
ns_register_filter preauth GET /junk myfilter
is registered? when
myfilter preauth
Like this.
fine.
is called, this would be pretty much comaptible with the aolserver
for the sim
Am 30.12.2005 um 19:19 schrieb Gustaf Neumann:
how will be the call, when
ns_register_filter preauth GET /junk myfilter
is registered? when
myfilter preauth
Like this.
is called, this would be pretty much comaptible with the aolserver
for the simple cases.
this would as well wo
Zoran Vasiljevic wrote:
Why would we need to process that optional argument in the first place?
Lets make the ns_register_filter as:
ns_register_filter when method urlPattern script
The "script" should be completely specified, for example
set arg "whatever thing"
ns_register_filte
Am 30.12.2005 um 12:46 schrieb Stephen Deasey:
On 12/30/05, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote:
Am 30.12.2005 um 03:28 schrieb Vlad Seryakov:
So, now with your patch it works the same way as aolserver? Then
keep it.
We will have to maintain a path between compatibility and cleanne
On 12/30/05, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote:
>
> Am 30.12.2005 um 03:28 schrieb Vlad Seryakov:
>
> > So, now with your patch it works the same way as aolserver? Then
> > keep it.
>
> We will have to maintain a path between compatibility and cleanness.
> Not for any price but at places
Am 30.12.2005 um 03:28 schrieb Vlad Seryakov:
So, now with your patch it works the same way as aolserver? Then
keep it.
We will have to maintain a path between compatibility and cleanness.
Not for any price but at places where it seems oportune.
I agree with Vlad.
Zoran
Yes, i forgot about aolserver's way and people using it. So, now with
your patch it works the same way as aolserver? Then keep it.
Stephen Deasey wrote:
I'm all in favour of simplifying and clarifying, even when it means
some work is required on existing code. But in the case of filter
proc ar
I'm all in favour of simplifying and clarifying, even when it means
some work is required on existing code. But in the case of filter
proc arg ordering there doesn't seem to be a clean way to write code
that will work on both AOLserver and NaviServer if the args are
reversed. Unless someone has a
Between three of us do we have a lot of code that uses filter with
aolserver's style of argument ordering?
If none, then i do not see why we cannot change it. Compatibility with
weird aolserver things never been our primary goal:-))
At least it will be one less confusing places in the code and
I added the comment because the argument order is confusing. We could
change the order, but it not be compatible with AOLserver. Do large
bodies of code such as OpenACS use filter args? I think they do...
Something we could change is registered procs. Currently, an extra
args is always passed
It still has this comment, so we can get rid of that comment and fix the
order at the same time:-))
/*
* This really should be: cmd why ?arg?, but why and arg
* are reversed for backwards compatibility.
*/
Stephen Deasey wrote:
Fixed in CVS a couple of days ago. My fault, I missread the o
Fixed in CVS a couple of days ago. My fault, I missread the original
code and thought that like registered procs, if you didn't explicitly
pass an arg a blank string was passed. Should work now.
On 12/29/05, Vlad Seryakov <[EMAIL PROTECTED]> wrote:
> It is in
>
> int NsTclFilterProc(void *arg
It is in
int NsTclFilterProc(void *arg, Ns_Conn *conn, int why)
why arg is added after script args
We can change it easily to always specify why first
Zoran Vasiljevic wrote:
Am 29.12.2005 um 20:54 schrieb Vlad Seryakov:
ns_register_filter trace GET * myfilter
calls now "myfilter {} WHY
Am 29.12.2005 um 20:54 schrieb Vlad Seryakov:
ns_register_filter trace GET * myfilter
calls now "myfilter {} WHY"
But *why* is this so? IOW, what is this empty argument
passed to the myfilter? Is this something we overlooked
or is it something done on purpose, or what?
I mean, maybe somebod
In all my code i never used args in the filters, i always define filter
as proc filter { args} so for me it does not matter the order of the
arguments. Logically, WHY should be the first arg.
Zoran Vasiljevic wrote:
Hi!
I believe you guys are more familiar with this stuff
as I am. Can you ple
Hi!
I believe you guys are more familiar with this stuff
as I am. Can you please comment?
Gustaf Neumann (XOTcl) is trying to get OACS to work
with our code and has some remarks. I'm forwarding the
relevant portion of an email sent to me today.
i made some changes to oacs such it works with n
24 matches
Mail list logo
