World: r3wp
[!Cheyenne] Discussions about the Cheyenne Web Server
older newer | first last |
Dockimbel 3-Mar-2009 [4093x3] | 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? :-) | |
Henrik 3-Mar-2009 [4096x2] | 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 :-) | |
Graham 3-Mar-2009 [4098x3] | 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 :) | |
Oldes 3-Mar-2009 [4101] | 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. |
Graham 3-Mar-2009 [4102] | 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. |
Dockimbel 3-Mar-2009 [4103] | Right, and the same good practice should be applied to all others dialects that include REBOL code, like VID. |
Kaj 4-Mar-2009 [4104] | I updated the Syllable build recipes for Cheyenne and UniServe to the new versions |
Dockimbel 4-Mar-2009 [4105] | Nice, is it online somewhere? |
Kaj 4-Mar-2009 [4106x5] | 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/ | |
http://syllable.cvs.sourceforge.net/viewvc/syllable/syllable/system/apps/utils/Builder/packages/cheyenne-0.9.19/ | |
The previous versions are included in Syllable Server and the new Cheyenne will be included in the next Syllable Server: | |
http://web.syllable.org/Linux/downloads.html | |
Dockimbel 4-Mar-2009 [4111] | Nice work. |
Graham 5-Mar-2009 [4112x8] | This is a video of my RSP pages showing binary at the top of the page. http://screencast.com/t/WD2j8PJtse |
The binary appears on a new RSP session | |
It will go away if I restart Cheyenne | |
Is there anything I can do to debug what is going on? | |
Each time I go to the RSP page, more binary appears above my html. | |
I'm running an command encapped version of 9.19 ( I presume there's no difference between the earlier 9.19 and the official release ) | |
you can try it yourself ... http://www.compkarori.co.nz:8000 | |
I suspect I did somethng while writing some buggy rsp code | |
Dockimbel 5-Mar-2009 [4120] | - The garbage binary data looks like compressed data. - "more binary appears..." => issue with a string! or binary! buffer not cleared or initialized as literal value instead of using MAKE. - "...above my html" => check your 'on-page-start event handler in %app.init.r |
Graham 5-Mar-2009 [4121x4] | on-page-start: has [][ set 't0 now/time/precise ] |
REBOL [ Purpose: "RSP environement init code" ] on-application-start: does [ ;--- add here your library / modules loading *do %private/captcha.r captcha/set-fonts-path %private/fonts/ ] on-application-end: does [ ;--- add here your library / modules proper closing ] on-session-start: does [ ;--- add here your per session init code ;--- ex: session/add 'foo 0 ;--- that can be latter accessed with : session/content/foo session/add 'user "guest" session/add 'hits 1 ] on-session-end: does [ ;--- add here your per session closing/cleanup code ] on-page-start: has [][ set 't0 now/time/precise ] on-page-end: has [pos time][ if pos: find response/buffer "</body>" [ time: to-integer 1000 * to-decimal (now/time/precise - t0) insert pos reform [ "<br><br><small>Processed in :" either zero? time ["< 1"][time] "ms.</small>" ] ] ] | |
nothing special ... | |
This has happened a few times now .. I mentioned it before. And usually only when I am rewriting RSP code. | |
Dockimbel 5-Mar-2009 [4125] | Are you using encmd v2.7.6 for encapping? |
Graham 5-Mar-2009 [4126] | yes |
Dockimbel 5-Mar-2009 [4127] | running on Linux? |
Graham 5-Mar-2009 [4128x3] | windows |
I need cmd for the odbc | |
If there's nothing I can do to debug this, I'll restart cheyenne | |
Dockimbel 5-Mar-2009 [4131x4] | You can restart it, I've a copy of the output. |
The garbage data seems to increase by 830 bytes each time. | |
I thought it might be an internal response/buffer corruption (not been clear after the request), but the compressed size of the page is only 442 (in deflate format). | |
You should carefully examine each use of response/buffer in your RSP code. See if you're not inserting in response/buffer a growing series? | |
Graham 5-Mar-2009 [4135x3] | server restarted |
the only response/buffer I have is ... | |
nothing | |
Dockimbel 5-Mar-2009 [4138x2] | You should at least have one occurence for the captcha image |
Need to go now, will give it a look tonight. | |
Graham 5-Mar-2009 [4140] | no, I do have this too ... response/buffer: xfdf response/set-header 'Content-type "application/vnd.adobe.xfdf" |
Dockimbel 5-Mar-2009 [4141x2] | ah :-) |
A suspect :) | |
older newer | first last |