World: r3wp

Join the discussions in the REBOL3 world...

[!Cheyenne] Discussions about the Cheyenne Web Server

older newer	first last
onetom 18-Apr-2011 [9846x5]	onetom ~/p/ob/jsondb $ curl http://localhost:8080/ver.r 2.7.8.2.5
	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...
Dockimbel 18-Apr-2011 [9862x2]	(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
Dockimbel 18-Apr-2011 [9887x2]	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 [9890x6]	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]
older newer	first last