World: r3wp

Cheyenne supports SSI

ahha.. plus 1 concept though, but thx for the remainder, i will give 
it a try!

Agreed, I don't use SSI myself. I don't know how easy it would be 
to replicate with RSP, because I don't use RSP, either :-)

what do u use then? direct output from .r scripts? (i used that too 
so far because the templating is done on client side w angularjs, 
so the backend is pure json(p))

hmm... how can i map a directory under a certain path in vhost? im 
trying this:
yp [  root-dir %~/p/ob/yp  alias "/public" %../public/ ]

then for curl http://yp:8080/public/angular-0.9.15.min.js  i get

HTTP/1.1 301 Moved Permanently
Location: /public/angular-0.9.15.min.js/

wtf?

i remember seeing something like "/some/path" [ options ] in a vhost 
config block, but i can't find anything about it now

i did a
~/p/ob/yp $ ln -s ../public public

as a workaround, but how can i achieve the same from the config file?

im guessing that i cant point out from the root-dir for one, but 
why?

I use my own app platform, which is based on a pervasive templating 
system

It's in REBOL, so the templating is done on the server. The concepts 
actually overlap with AngularJS quite well, but it's serverside

Kaj: overlap w angular? as in u have 2 way databinding? do u have 
some example sites?

It depends on the definition, but that's the direction I'm moving 
in. The structure is roughly MVC, and I have a method of updating 
web pages without the browser having to know what it means

Try REBOL is the first dynamic site I've done that way. You stay 
on the same page, send in data to a service interface and get data 
back that updates arbitrary parts of the page

So you get conceptually the same effect as AngularJS, but it goes 
through the server. One of my goals is to maximise the REBOL part 
and minimise the JS part. AngularJS pulls everything in the client 
and is thus tied to JS and the browser incompatibilities that go 
with that

Obviously it's nice to be independent from the server - if you can 
get it to work cross-browser. But I always thought we have View for 
that. Also, it seems nice to have the browser do input checking, 
but if you want a robust app, you will have to get the server to 
guard its own consistency and end up writing all input checking twice

In general, I notice that almost all web platform projects (and operating 
system projects for that matter) are either very focused on the server, 
or very focused on the client, apparently depending on the preference 
and abilities of the founders. This doesn't make sense to me: a network 
app by definition needs to deal with both sides of the connection, 
and find the best balance

i wish rebol/view was that good to replace the browser, but im typing 
this on a mac w ugly, aliased, miniature fonts and i can't even use 
the maximize button because it fucks up the screen size and layout...

angularjs is surprisingly backward compatible, btw... but serverside 
validation is still a must of course.

in this particular project we tried view, btw, but we need it on 
a tablet later in a warehouse, so /view is not an option at the end 
:(

is the source code for TryREBOL available somewhere?

Only the client code

Yeah, we're waiting for R3/GUI/ReBrowser...

AngularJS specifies a minimum of IE6, and IE7 for CSS, and no word 
about Opera and less popular browser engines. My system works from 
IE5 on (anything with AJAX)

Why wouldn't you be able to run View on a tablet?

by tablet, i meant something usable, like ipad or galaxy tab... do 
u know any tablet pc w capacitive touchscreen, half day battery life 
around ipad price?

No idea, but there are many now, so there must be a number of choices 
for the price of an iPad

im loading libraries from on-application-start, then i was hoping 
to load some static data too, but the words i assign there can't 
be found in my script later.

the script is called via an alias though which was specified within 
a webapp section.

on-application-start: does [
do %some/lib.r
db: %db/dir/some/where/
]

httpd.cfg:
vhost [
  webapp [
    alias "/xxx" "db.r"
  ]
]


db.r can't access the db variable, although it can use the words 
defined in the library loaded by 'do

ok, probably im trying to do something forbidden there


6/5-17:27:41.971934-[Logger] New request: T6/5-17:27:41.948903-## 
Error in [task-handler-55484] : Make object! [
    code: 312
    type: 'script
    id: 'cannot-use
    arg1: 'path
    arg2: 'none!
    arg3: none
    near: [switch debug-banner/opts/error [
            inline [html-form-error err file] 
            popup [debug-banner/rsp-error: make err [src: file]]
        ]]
    where: 'protected-exec
] !

which part of this code might cause the - otherwise not very informative 
- error above?

  parties: map-each f read db [to-object load db/:f]

now, i got back the source of the aliased rebol script

wow!!!! there was an extra closing bracket before the end of the 
script and it completely derailed processing and i got back the script 
source itself as a response

Can you send me a minimal version of your script producing this error? 
I would like to see how it can affect the internal code so deeply.

im chopping it down now

did u get it? no immediate thoughts?

I got it but was busy with other tasks. Will look into it in a few 
minutes.

Error reproduced. Tested with similar code within RSP: <% ] %> is 
producing an error, but it is handled nicely.

onetom: fix pushed for the issue you have reported. Let me know if 
it works ok for you.

im getting different errors now, but trying to dig to its roots

confirmed: my script works w r135 but not w r136 (this is a different 
script)

** Syntax Error : Missing [ at end-of-block 
    ** Where: none 
    ** Near:  "(line 5) ]" 
thats all i get as an error msg

hmm... it's a .r file but it's in rsp format, so no rebol header 
but <% %> tags.
so i guess it's the right behaviour

if i was calling the script .rsp and also bind-extern .rsp to the 
RSP handler then it worked too.

is it something hardwired in cheyenne, if the extension is .r then 
is should be handled as a plain rebol script?

bugfix worked. thx

s it something hardwired in cheyenne, if the extension is .r then 
is should be handled as a plain rebol script?

 Yes, .r scripts are processed as plain REBOL scripts but with the 
 addition of the whole RSP API since r100 (http://code.google.com/p/cheyenne-server/source/detail?r=100).


It has been officialy documented on the wiki only recently: http://cheyenne-server.org/wiki/Rsp/Basis
("No-template scripts" section).

Doc, did you get a chance to debug fast-rebol-cgi?

my quesstion was rather: where and how is it hardwired that .r is 
executed in rsp context? is there an internal bind-extern RSP [ .r 
] happening. do i need the rsp module for this alone or do i need 
that action module too? stuff like that. otherwise it feels pretty 
magical

we have even experienced very strange behaviour with the
unless value? 'some-func [ do %../lib/obj.r  do %../lib/oid.r ]

tactic. our to-object function defined in obj.r didnt have a value.

we modified the script, did not restart cheyenne and it started working!

it was just happening with the binary version of cheyenne, iirc, 
so i dropped the case...

Kaj: I thought it was fixed since r131: http://code.google.com/p/cheyenne-server/source/detail?r=131

AFAIR, mod-action is required for mod-rsp. bind-extern RSP .r is 
required to send .r scripts to the RSP handler in workers.

See April 25 above. I used r135:

It recognises the fast-rebol-cgi keyword in the globals now, but 
it doesn't seem to do anything. It seems to try to execute REBOL 
code as real CGI. It tries to use the shebang line and has permission 
problems with CGI files that it didn't have before