World: r3wp

Graham: you can set your webapp (or at domain level) in debug mode 
(using the 'debug keyword in config file). If the debug mode could 
be tested, it could allow you to enable/disable the captcha system 
(or anything else) based on the working mode (debug / in production). 
I'll add that to the todo list also.

That could be already tested right now, thought. Just use : 

debug?: to-logic find request/config 'debug

(the 'on-page-start handler could be a good place for that)

doc, what exactly is a session object?  Is it something that is server 
side only?  Or is transmitted to the client as a cookie?

Just wondering how much data I can store in the session object.

A session is a block! of name / value pairs that is kept in Cheyenne's 
main process and exchanged with worker process. A synchronization 
system is there to avoid concurrency issues. The SID sent by cookie 
to the client is just a lookup key. When sent back to the server, 
this key allows to identify the right session object to pass to the 
RSP script in a worker process.


You are only limited by memory, but remember that the session object 
is MOLDed / LOADed and exchanged by TCP twice for a RSP request. 
So, in order to keep your RSP pages fast enough and scale well with 
a growing number of active users, keep the session block! as small 
as possible.

I guess it boils down to whether the slow down with large objects 
is still faster then requesting the data from the db.

This is precisely where Cheyenne could benefit a lot from a multihreaded 
REBOL kernel : no more need to MOLD / LOAD session block and request 
object, no more need to exchange it through TCP with other processes...That 
would allow a big boost of RSP performances and reduce Cheyenne's 
whole memory usage.

I think that the DB will be slower, but it depends on how big are 
your "large objects".

I suspect only a few mbs

Wow...that's huge! Why do you need to maintain so much data in session? 
Why not store it on disk?

If I want to keep all the data for a patient in a session .. and 
have mutliple  patients, I was thinking of keeping all the results, 
consults etc in the session object.

That way I wouldn't have to keep fetching the data from the sql db.

Or, if I have just the one patient as an object .. then if I move 
to a diffferent rsp page, and then back again, I don't have to refetch 
all the data.

I'm just wondering how to simulate tabs in a rsp page ... do I have 
to recreate the tab each time I switch to it, or can I keep all the 
data in a session.

Do you really need several megabytes of data to display each page? 
That sounds very odd to me.You should store your data in a DB on 
disk and only request from DB the data needed for display.

If you've requested the data once, why not cache it in the session 
object ?

I guess that's the general question.

Tabs: that's a client side question to solve using HTML/CSS/JS. Tabs 
are not a standard HTML element, so the solution depends on  how 
you build your tabs, how you want to manage them,...

General answer: session data is exchanged by TCP for each RSP request, 
so the performance penality can be high for huge session data. That 
also means that your server won't be able to handle a lot of user 
session at the same time.

Ok, premature optimization then.

In one of my RSP based app, I have pages with tabs. I use 2 different 
approach :
 

- for tab panels with data cross-dependencies : I use a unique RSP 
script generating a page with a unique <FORM> tag and each tab content 
is simulated by <DIV> sections that I show or hide (with JS) depending 
on the selected tab.


- for tab panels with no cross-dependencies : I use a separate RSP 
page for each tab content. The tab bar is a unique RSP script included 
by each "tab content" script.

I currently doing the latter ... and I guess it's better to let the 
client store the data in their browser in a hidden div rather than 
the server store it in a session.
Not sure what you mean by  unique form tags though.

That just means that, in that case, when I have multiple forms spread 
out in several tabs, I use a unique <FORM> tag to be able to send 
all data together when I need to save all the forms.

oK.

btw: I started using dobedash's sqlite lib with cheyenne for my 3rd 
webapp with cheyenne. It says it takes care locking.. etc for writing 
to it from multiple processes so that problem should be gone in this 
case

Let us know if it's reliable, I guess that a lot of people here who 
would like to know (including me).

ok, I will .. (you mean reliable in the terms of locking or something 
else?)

Doc, I am making that form -> validation -> v. notices display in 
form ...  I will post code if it works out well

Any feedback on this filter-validate-process dialect is velcome.. 
(it is meant for processing posted form data)

first word in row is request field name ;;; req | opt  is  required 
| optional + default value  ;;; than you can have a chain of aditional 
validators like int , string , email, url , one-word ;;; then you 
can have check which executes your custom code and if it returns 
a string it uses it as validation notice ( to check something app 
specific or in DB for example ) ;;; then you can process the value 
with do and again custom code the returned value of that block of 
code is set to that field ..

filter-validate-process-example: 
[
	id req and int .
	username req .

 email req and email check ( either email-exists email [ "email taken"] 
 [ none ] ) .
	website opt "" do ( to-visible-url website ) .
	adress opt "not given" .
]

I am not 100% on few things ... should I use short names like req 
opt  or whole required optional ... and more technical about check 
and do (I will rename this to proc or process )  .. should I create/bind 
to words that are the same as field names , like this upthere ... 
or maybe use something like this so you use ( to-visible-url this 
) I don't like creating a bunch of words that won't get used mostly... 
but I thought I need to so I can use this for typical password / 
retype password example like this 
	...
	password req .

 password2 req check ( either password == password2 [ none ] [ "passwords 
 don't match" ] )  .
	...

but I figured out I could use current and previous then this example 
and probably some others will work anyway.. and I can bind in do 
( code ) anyway if I really need custom variables

	password req .

 password2 req check ( either current == previous ) [ none ] [ "no 
 match" ] ) .

I will go with this way

Defining a good dialect (simple, short, efficient) isn't an easy 
task. Chris did some work about such form validation dialect in QM. 
See http://www.rebol.org/documentation.r?script=filtered-import.r

nicely done, thanks for the link

Cheyenne v0.9.19 officially released : http://www.cheyenne-server.org/blog.rsp?view=19

I found a possible bug in RSP yesterday: When RSP gets the values 
passed to it as get query parameters, it removes url-encoded html 
tags and comments from the values. This is not correct with values 
that come from a textarea, or probably other values as well. I haven't 
tested with multipart/form-data encoding yet.


This might be a setting change rather than a bug in RSP, but if so 
then show.rsp should be changed to not strip tags from values and 
then html-encode the values when shown.

I think RSP also removes tags from posted urlencoded data too, but 
I didn't notice until I tested with get.

If it is a setting change, I would like to edit my local copy of 
show.rsp accordingly asap. I'm using show.rsp for browser analysis.

IIRC, it just apply a DEHEX, but I'm not sure to understand what's 
the issue. I agree with adding html-encode in %show.rsp. Could you 
provide a short example?

If you try with http://localhost/show.rsp?test=<tag>, the resulting 
page will show you  test : "". That doesn't mean that the RSP engine 
stripped off the tag, just that the browser doesn't know how to display 
it, so it hides it. Look into the page source, the passed value is 
here.

Adding html-encode in %show.rsp allows you to see passed tags values 
(you can add it just before all "mold value" expressions.

I was playing around with rsp form submission the other day, and 
I found that values were being persisted.

So, even when the values should have been none, it was displaying 
values from the previous form's submission.  

I had to explicitly set each value to none prior to parsing the submission 
data.

Can you be a little more specific please?  Are you talking about 
"values" from request/content or your own one?

I'm programming RSP scripts since than more a year now on a daily 
basis and I never noticed such behaviour with values received from 
form submission and accessed through request/content (which is the 
way you should use to access passed values).

from request/content

basically:

data: select request/content 'submitteddata ( from a textarea )
parse/all data [ thru "phone" copy phone to etc  ]

print the parsed data ... but the printed data when none would produce 
data from a previous form submission .. weird as though it were preserving 
the context somehow.  

fixed it by initializing all the variables I am expecting to parse 
out to none at the top of the rsp page.

This is for a web app

What I am doing is taking a text screen dump from an AS400 terminal 
( see http://synapsedirect.com/forums/permalink/7675/7675/ShowThread.aspx#7675
) and parsing the data so that I can grab the patient demographics 
and add them to the database.

demographics and import them into the database.


This is now saving this user from having to manually enter them ... 
there being no bridge from the mainframe database.

I once used the telnet scheme from F. Sievertsen to script and query 
automatically a host system. Maybe this can help too.

I suspect it's outside the abilities of the user ... the system is 
pretty much locked down.