World: r3wp

It looks that FF converts < > chars automatically inside PRE. It 
should be converted on the server side I think.

Can someone give me some guidance on the following I keep getting 
a decoding error.

<%
 	fname: request/content/fname
   	lname: request/content/lname
   	spouse: request/content/spouse
	address: request/content/address
	city: request/content/city
	state: request/content/state
	zip: request/content/zip
	h_phone: request/content/h_phone
	c_phone: request/content/c_phone
	email: request/content/email

 do-sql 'bugs ["INSERT INTO names VALUES (?,?,?,?,?,?,?,?,?,?)"fname 
 lname spouse address city state zip h_phone c_phone email ]
%>

What does trace.log say?

BTW, I normally do it this way

fname: any [ select request/content 'fname copy "" ]

so that the variable is always a string ...

Also, I specify the field names ... so I've never used your syntax


sql: do-sql 'bugs [ {insert into names ( fname, lname, spouse .... 
) values (?, ?, .... ) } fname lname .. ]

Thanks Graham I'll give your methods a shot. I'm just a newbie trying 
to learn so I put the listed code together from what documentation 
I could find.

Is there any inbuilt way how to store per-session data which are 
not sent to client as a cookie?

Or the session is used only to store the data inside cookies?

There's *no data* sent as cookies. Cheyenne session cookies are just 
hash keys.

So I can strore sensitive informations inside? Good to know.

jim: it's also good to use  validate  function before you process 
the request content!

RSP sessions purpose is to provide a way to store temporary persistent 
data efficiently (in memory) across client requests (the alternatives 
are storing data on disk in flat files or databases). RSP session 
data is lost when the session expires or when you restart Cheyenne 
without using the 'persist config directive.

Right, for both Jim and Graham, 'validate is the way to go : http://cheyenne-server.org/docs/rsp-api.html#def-23

What about improving validate to produce default values for missing 
content?

(produce = provide)

Validate already assign a 'none value to missing parameters.

assigns

Yes... but in most cases you don't want  none and you and up using 
code similar to Graham's

Also the Jim's code does not looks much friendly - too many request/content/ 
paths.

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