World: r3wp

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.

I guess I need to sit down and recreate this .. but thought I'd mention 
it make sure it was aberrant behaviour.

What about closing your data in a context?

Let's clarify a few things :


- Request/content is working OK in your example, there's no issue 
with that.


- Using variables in PARSE rules without initializing them is a bad 
programming practice in my book. You *should* initialize them before 
using them (unless wrapped in a function which will do the work for 
you). If your parse rule fails, your code may error out (or you may 
get an unexpected value) when trying to print 'phone because it hasn't 
been initialized. 


- You seem to expect that RSP script will be evaluated in a fresh 
REBOL session each time. This is not the way RSP works. RSP uses 
persistent pre-forked processes for performances. If you expect a 
fresh REBOL session each time, then this is the CGI model which is 
an order of magnitude slower than RSP. 


- Even if RSP processes are persistent, they can be restarted or 
killed and you can't control which process will executed your script, 
so, just as a warning, you can't expect that a "global" variable 
will be still there for the next RSP script evaluation. If you need 
value persistency, use a session variable or write it to disk.

RSP uses persistent pre-forked processes for performances
 <- that's what I love about RSP. :-)

That's the main feature making Cheyenne/RSP a much faster solution 
than Apache/CGI for server-side REBOL code.

In theory, it should be possible to set to none each new webapp variables 
used in RSP scripts by querying the webapp context object. In practice, 
I'm not sure it can be made 100% reliable because you can always 
declare words using SET in global context (which would be much more 
difficult to clean up without breaking the RSP engine). The other 
reason is that, as a side effect, it allows some dynamic code caching 
like this one :
<%
	if not value? 'my-lib-loaded? [
		do %private/my-lib.r
		my-lib-loaded: yes
	]
%> 

This can be used when you don't want to pre-load some libs from the 
on-* handler, but load them dynamically, only when needed. So you 
pay the cost of loading only once for each RSP process when the script 
is first called (and you can clean it when no more required by, for 
example, setting the word referring to the lib context to none)

Yes, that gives quite extreme performance. It's an elegant way to 
solve the problem of caching that others are providing via expensive 
slap-on solutions rather than by design. This is also why I got the 
idea that you would be able to create VID-like applications in the 
browser, because data is always resident server side, like an app.

The session data problem gets reversed: You have to avoid data to 
spill over to the next user of the app. This could provide a very 
unique way to handle form data, by simply dumping POST data in a 
resident object. Then you can quietly decide what to do with that 
data without having to worry that it's forgotten at the next page 
load.


Session data is about storing that data in a context isolated for 
that user. I've not studied closely how Cheyenne handles session 
data, but I've been working a bit on the form issues for REBOL/Forum.

I can implement a clean-up routine for RSP variables declared in 
a webapp context, but this would be a partial solution (won't clean 
up global space), and in all cases, you *should* initialized all 
variables before using them either by declaring them in a function! 
as local words or by explicitely setting them to a default value. 
Such clean-up routine could be usefull to enhance security by avoiding 
to reveal other user data in case of a RSP script programming error.


Btw, you can already detect uninitialized variables in your RSP code 
by running Cheyenne with the -w 0 command line option. This would 
tell Cheyenne to use a single RSP worker process that will be restarted 
after each request (CGI like beahaviour). An uninitialized variable 
will likely error out in that case.

Henrik: session data context is here to ensure that your data will 
be :
- preserved from being lost whatever happens to RSP processes
- isolated from other users

Having a Cheyenne running locally using a browser window to display 
VID dialect looks like very doable. I think that even 'move events 
would work fast enough. That would solve a lot of current View/VID 
issues while providing a cross-platform GUI. Add a proxy service 
to Cheyenne, and you got a nice RIA platform with online/offline 
working capabilities.  Anyone rich enough here to sponsor such project? 
:-)

Dockimbel, that might solve some problems I had with form submission.


My intent with forms was to provide an easy way to have all form 
data provided by the server via an object. When you create a new 
object it would hold info for when the form was created and a unique 
ID for the form.

Through that you can tie a form instance to a specific browser instance, 
and when the form is submitted, you can do server-side verification. 
If the verification fails, the form object remains and the page is 
redisplayed. If the form object validates, then the form object is 
removed or copied away from the block of existing form instances 
and can no longer be used from that form instance, if you attempt 
to submit again. This would eliminate accidental double submission, 
although not regular spamming. By having that framework, setting 
up a flow for how to handle form data, server side, would be simpler.

This doesn't sound like so much, but I happen to have an HTML dialect 
around, where I can create forms as objects in a simple way, and 
applying actions or handlers to forms, makes it much more like programming 
a real GUI. It could probably scale down to single text fields and 
a bit of AJAX.

I would initially not try to do VID graphics directly, but to do 
something like this:

html-view [
	text (reform "The current server time is" now/precise)
	display-name: text
	name: field

 button "Submit" [set-html-face display-name get-html-face name] ; 
 'name is stored on server too
]

... well, let's see how easy that is in JS :-)

doc, for persistent variables I am storing them in the session object. 
 I just hadn't expected some values to persist outside the session 
object as well.

Now that I know, I can be more meticulous in parsing etc.

Anyway, I stumbled across the correct solution it seems :)

There should be big sign somewhere, that people should enclose the 
variables set by parse in context or as function's locals. And it's 
not only Cheyenne related.

I normally do this, but for some reaason I was thinking cgi instead 
of rsp, and so thought I didn't need to do that.

Right, and the same good practice should be applied to all others 
dialects that include REBOL code, like VID.

I updated the Syllable build recipes for Cheyenne and UniServe to 
the new versions

Nice, is it online somewhere?

So far, for the new versions, only the recipes for building from 
source:

http://syllable.cvs.sourceforge.net/viewvc/syllable/syllable/system/apps/utils/Builder/packages/uniserve-0.9.33/