World: r3wp

Request parameters are used to transport data from client to server. 
If a parameter is not sent, having 'none seems appropriate. Setting 
them to anything else "by default" will make you loose this important 
information.

Btw, you can easily write (when needed): var: any [request/content/var 
<default value>]

Jim's snippet could be rewritten like that : 
<%
	if none? validate/full [
 		fname	-		*
   		lname	-		*
   		spouse	-		-
		address	-		-
		city		-		*
		state		-		*
		zip		integer!	*
		h_phone	-		*
		c_phone	-		-
		email		email!	*
	][
		req: request/content
		do-sql 'bugs [
			"INSERT INTO names VALUES (?,?,?,?,?,?,?,?,?,?)"
			req/fname
			req/lname
			req/spouse
			req/address
			req/city
			req/state
			req/zip
			req/h_phone
			req/c_phone
			req/email 
		]
	]
%>

I know, but than I can write as Graham var: any [select request/content 
'var <default value>] without validate... At least if the value is 
expected to be a string!.

I'll think about that in the next release. I have plans to improve 
the 'validate function to be able to specify more constraints. What's 
missing the most currently is an efficient way to map a list of words 
to a database record (especially for writing).

Maybe it could be implemented on the sql side, because as you build 
the query, you must validate it again to get correct escaping, no?

When the query is built, passed arguments are escaped depending on 
their own datatype and not depending on the target field in the table. 
This could be improved too by using an abstraction layer upon databases, 
giving you access to a logical data model instead of the physical 
model. I'm currently brainstorming on such abstraction layer to see 
the pros&cons.

I must have been asleep when 'validate was added!

It's there since the beginning. :-)

Does Cheyenne support R3 CGI scripts?

I believe you should be able to run any CGI script with Cheyenne. 
If you search back in this topic, Dockimbel specifically mentioned 
something about running R3 CGI scripts.

Cheyenne's CGI handler reads the first 512 bytes of a CGI script, 
if it contains "REBOL" followed by a [, it loads the script and evaluates 
it. If header is not found, it reads the shebang line and run the 
script using CALL (so as a separate process). So, in order to run 
R3 scripts, you need to patch Cheyenne's CGI handler to run all scripts 
with CALL, or provide a R3 CGI script with shebang line and extra 
text (512 bytes) before the REBOL header (R3 should ignore the extra 
text).

ok, thanks for the info.

On WinXP, I can not get Alias to work... e.g.  alias "/docs" %md.rsp 
    Is there any debugging mode to see what Alias thinks I am asking 
it to do?  From my testing, the .rsp script is not being invoked. 
 Can there be  an Alias in each sites definition in the config file?

Testing locally with latest SVN revision: it fails too. It's a regression. 
I'll fix it asap.

Good ... I guess ... I thought I had lost the ability to set a parameter. 
 If you are looking, I also had trouble with the worker-libs and 
had to enter absolute addresses to get them to work ... %/c/cheyenne/www/private/mysql-protocol.r

New CureCode instance for Softnnov's OSS projects: http://curecode.org/si/
 (you can import your REBOL3 CC account on the new registration page: 
http://curecode.org/si/register.rsp, just use "rebol3" as instance 
name).

MikeL, I've added the alias issue to the new CC instance for Cheyenne. 
I let you add a ticket for the path issue with worker-libs.

Is there any debugging mode to see what Alias thinks I am asking 
it to do?
 


Yes, with at least verbose level 2 (-vv), you get the "Translated 
file:" log line showing you the target file once config file rules 
have been applied.

Thanks for the verbose answer. I will try it.

For the CureCode I have set a new account request in and am getting 
no email. I went back to my Curecode R3 account and requested the 
password email and so far no email.  For new request, status says 
'account not yet activated'

Looking into that...

Have you looked into your spam folder?

From the logs on curecode.org, both emails have been rejected by 
your email SMTP server. It seems like a SMTP issue (not sure yet 
from if it is from the server or client side). Anyway, I've validated 
your CC accounts, so you can log in.

Got one email now.. Thanks

Ah good, maybe it was just delayed by a SMTP greylisting protection.

Your SMTP server sends two 220 greetings lines instead of one which 
doesn't comply with RFC2821, so it is rejected by Cheyenne's MTA 
as an error. I'll improve the MTA to accept such protocol deviations.

what to do to be saved in logs/default-access.txt user-agent and 
referer ?

Thanks Doc for this debugging work.

You need to patch 'logging event in mod-static to save them. There's 
probably a standard format from Apache for that.

ok. thanks

You can also add a wish to CureCode for that feature if you want 
me to implement it. ;-)

has anyone used the localisation framework of cheyenne?

I digged into it a little and I don't know how to make it load other 
than default language en

<% 
locale/set-default-lang 'en
print say "test" 
probe locale

print "<hr/>"

locale/set-lang 'fr
print say "test" 
probe locale
%
this generates:

test make object! [ path: %www/cebelca.biz/lang/ lang: 'en current: 
make hash! ["lang" "test" ] default: make hash! ["lang" "test" ] 
......
<hr/>

test make object! [ path: %www/cebelca.biz/lang/ lang: 'en current: 
none default: make hash! ["lang" "test" ] ...
--

after I set lang to fr I have file in fr/fr.cat it says current: 
none (so it didn't load it)

if I reverse the fr and en in code in first case default and current 
are still en and in second they are both en.

It seems like it can't find fr/fr.cat in either of these cases

case = examples , the one up there and reverse

I suspect that directory lookup is different for default 'en and 
when you set-lang , set-default-lang

I found in source: ;--- Define the localization resources directory 
(relative to the webapp) .. now I moved the test to webapp, I had 
it on the frontend before but it behaves the same (I have binary 
release 0.9.19

I will try with the source version from SVN

same behaviour

file: join path [mold id slash mold id ".cat"]    ; current dir is 
in the webapp aleready so the path to file doesn't resolve
unless exists? file [return none]

I don't know what is the right solution in the global context, differentyl 
calculated path , different current dir .. so it's best you solve 
it :) .. I made a hack/fix so I can work on

great, it works.. also outside webapp

that static form for localised strings is a great idea #[...] 


does localisation effect performance much? I suppose it increases 
RAM usage since app holds the two hashtables in memory (which is 
needed I know for speed)

the #[..] is awesome idea. I have tons of javascript that would otherwise 
become an ugly mix of javascript and rebol

I don't recall anyone using the localization framework besides me 
and now you. :-) This framework is still experimental, it might be 
not suitable for a big application as it relies on a single namespace 
(using same words in differents pages will give you the same translation, 
this is not always desirable).

I'm not aware of issues wrt 'set-default-lang, but I must admit that 
I've never used it, I just switch the languages in my browser for 
testing.

Please add a ticket for that issue at http://curecode.org/si/view-tickets.rsp.

I agree that #[...] really makes things easier and cleaner. Performance 
impact is not significant, the overhead is just a string! PICK in 
a block with a static index as argument (that's one of the nice advantage 
of compiling RSP scripts). OTOH, the SAY function has to do a hash 
table lookup to get the right index (so a tiny little bit slower 
than the literal form).

Good. I have a lot of javascript so #[] really saved my day. I had 
started with >element.innerHTML = "<%= say "some text" %>" and element.innerHTML 
= "#[some text]" is 10x better :)