r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!Cheyenne] Discussions about the Cheyenne Web Server

onetom
18-Apr-2011
[9847x4]
also my rebol exe works like this:
>> system/version
== 2.7.8.2.5
>> body-of context [a: 1 b: 2]
== [a: 1 b: 2]
i guess u left of the r3 compatibility mezzanines from the encapping
if there is such a thing :)
Dockimbel
18-Apr-2011
[9851x3]
I guess my Cheyenne build scripts are missing a R2/Forward specific 
include.
Found the issue, my Linux and OSX build scripts were corrupted with 
an older version pointing to 2.7.6 include files. I will need to 
rebuild them.
json.rsp:
<%= probe request/content %>
<%= probe as-string request/parsed/arg %>
<%= probe as-string request/parsed/content%>
<%= probe request/parsed/arg %>


>> probe read/custom http://localhost/json.rsp?test[POST {{"a": 
1, "b": 2}}]
connecting to: localhost
{[{"a": 1, "b": 2} "" test ""]{"a": 1, "b": 2}test
{{"a": 1, "b": 2}}{"a": 1, "b": 2}
{{"a": 1, "b": 2}}{"a": 1, "b": 2}
test
test
}


Some corruption is occurring, request/parsed/* should be left untouched.
onetom
18-Apr-2011
[9854]
thx, doc for the quick responses! i feel a bit quilty though, coz 
u can't work on red instead, but hey, let's make what we already 
have bugfree 1st. these needs to be fixed even if we run it over 
red, right? :)
Dockimbel
18-Apr-2011
[9855x6]
Right, important bugs have to be fixed asap.
Ok, false alarm, no bug in RSP request decoder:

json.r
<%= mold request/content %>
<%= mold as-string request/posted %>
<%= mold as-string request/parsed/content %>
<%= mold request/parsed/arg %>


>> print read/custom http://localhost/json.rsp?test[POST {{"a": 
1, "b": 2}}] none
connecting to: localhost
[{"a": 1, "b": 2} "" test ""]
{{"a": 1, "b": 2}}
{{"a": 1, "b": 2}}
test

The <%= in addition to PROBE was producing a misleading output.
onetom: your concatenation issue was caused by the usage of TO-STRING 
instead of MOLD.
Looking into the missing mezzanines issue in Linux binary...
Re-released all v0.9.20 binaries to fix the missing 2.7.8 mezzanines.
i have a couple of ideas how to hack this, but what would be the 
correct" way?"


You could try using the ALIAS config option. Add this to the httpd.cfg 
file in a domain section (not sure if it would work in a webapp context):

    alias "/rest" %rest.rsp

and call your REST resources with:
    /rest/asd 
    /rest/qwe


In %rest.rsp, you can put your URL parsing code to produce a "REST 
routing" and return the JSON object. It might also work with "/" 
(untested).
Maxim
18-Apr-2011
[9861]
Doc, wrt req/in: make req/in   []    so far it works flawlessly. 
 I'm using this to store computed data from an early phase and sending 
it to the handler later.  This allows me to prevent double or tripple 
processing the same thing (a decision based on the url)
Dockimbel
18-Apr-2011
[9862x2]
Extending the req/in object! is a good solution. I should maybe add 
a 'user field in request object for storing custom mod data...
(just to make it cleaner)
Maxim
18-Apr-2011
[9864x3]
don't know, since then more than one mod might start to clobber it, 
and we'd be fighting for the space (same difference, just one level 
down  ;-)


and, since those extra bytes get molded/sent/loaded to and from handers... 
it seems like waste when for most people this data will not be used. 
   I'd actually rather document how a module should expand a request... 


like spelling any new word, starting with the mod's name to prevent 
collisions.
and documenting that its supported and safe too  :-)
(since it seems safe so far)
Dockimbel
18-Apr-2011
[9867]
Agreed.
Maxim
18-Apr-2011
[9868]
(no need to go down the RoR path  ;-)
onetom
18-Apr-2011
[9869]
Dockimbel: the alias "/" %x.r works too. beautiful.
Dockimbel
18-Apr-2011
[9870]
Good! :-)
ChristianE
18-Apr-2011
[9871x4]
Should the following .rsp script work and deliver something like 
... <p>123</p> ...
<html>
  2   <head>
  3     <title>Test</title>
  4   </head>
  5   <body>
  6     <p>
  7       <%= ajoin collect [repeat i 3 [keep i]] %>
  8     </p>
  9   </body>
 10 </html>
(sorry, ignore the line numbers)
I tend to use COLLECT a lot in REBOL scripts, but it seems it can't 
be used with Cheyenne.
Dockimbel
18-Apr-2011
[9875]
Which Cheyenne version are you using?
ChristianE
18-Apr-2011
[9876x4]
All I get is
#[object! [ code: 302 type: script id: no-arg arg1: arg1 arg2: keep 
arg3: #[none] near: [err/arg1] where: reduce-error ]]
wheter I'm in DEBUG mode or not..
I'm running version 0.9.20.125
Dockimbel
18-Apr-2011
[9880]
Seems that the RSP error catching has some trouble with COLLECT.
ChristianE
18-Apr-2011
[9881x6]
Another error I'm running into fairly regular is
#[object! [ code: 502 type: access id: cannot-open arg1: %/usr/local/bin/cheyenne/ 
arg2: #[none] arg3: #[none] near: [change-dir save-path compress-output 
unless response/buffered? ] where: #[none] ]]
when doing something
like
<% ... query: "select * from database.table" ... do-sql query ... 
%>
Cheyenne doesn't like the QUERY word being overriden. But doing so 
is probably just silly on my behalf.
Dockimbel
18-Apr-2011
[9887x2]
QUERY is a REBOL native function
You should *never* redefine such word that is used in several mezzanines.
ChristianE
18-Apr-2011
[9889]
Yeah, so, as I said, just silly on my part.
Dockimbel
18-Apr-2011
[9890x7]
The issue with COLLECT is caused by DO. In RSP environment, DO is 
redefined to bind argument code to webapps execution contexts. The 
 RSP mezz DO has a fixed arity (= 1) while the native DO has a variable 
arity (= 3 inside COLLECT), hence the error.
I see no simple way to fix that on the RSP side as they is no reachable 
way to emulate the "variable arity" at mezz level.
So, I'll see if I can patch COLLECT instead.
Hard to fix COLLECT without destroying Brian's code pattern...
I will ask BrianH for that.
Ok, I've found an (obvious) patch for COLLECT. A reference to the 
DO native is kept in RSP (*do). So the following patch (run in global 
context) would solve the issue:

if pos: find second :collect 'do [pos/1: '*do]
I guess other new mezzs in 2.7.8 might be using DO internally too, 
they would need to be patch one by one by Cheyenne to be used in 
RSP context.