World: r3wp

I pretty much gave up on using the app-init.r file ... it is supposed 
to be local to the app, but I found variables spilling to other apps

The question is the remark you make to Terry: I'm trying to get away 
from mixing html and rebol inside the view part of the page ...  
this type of stuff   Hello <%= select session/content 'username %> 
... looks hard to maintain.

That's my remark ... what's your question?  :)

What need for clean templeting is access to the html source file. 
I'd use the element ID to match with a backing .r file variable / 
component model. No scripting, no tags in the html file. So the question 
is, how can cheyenne let me map these two files?

/path-to-file/page.html mapping to /same-path/page.r. From here, 
page.r works on the response/buffer.

So chyenne loads page.html and does what?

You want cheyenne to load page.r instead?

allows a mapped file to access the response/buffer before it returns 
it.

Yes, where page.r manipulates page.thml

maybe you need this http://cheyenne-server.org/docs/rsp-api.html#def-56

exactly. I tried that tonight as I look at cheyenne for the first 
time. However, the on-page-start/end do not seem to work (in debug 
mode). The instructions are so simple I wonder why it would not work 
though.

are you using rsp pages?

And is it inside a webapp?

Aha. No. I guess that's where it is. I used .htm. Yet I found that 
the script in the .htm file also is processed. So there is a difference.

Yes, inside a webapp.

It sounds like you want to do what I'm doing here http://rebol.wik.is/Cheyenne/Page_Title/HTML_dialect_demo
 

but have the html page act as the template

whereas i put both together

the element id or divs are used to control the layout of the template

Yep. Yet, to my mind, it does not achieve my objective.

There is no way a page designer would get into this mess. Appealing 
though.

in that case .. the rsp page would just load the html ... no real 
difference

What I need, is a clean html page that my code would not touch directly.

well, this has limitations.. what say you want to update all the 
javascript ??

and most html is dynamically generated for me ...

From the html page? The javascript would only execute after the response 
buffer is closed.

I'm assuming that the JS and HTML are part of your template

so say your library updates . .you have to update all the pages that 
use the js libraries

The JS is executed by the browser once the buffer is returned to 
the browser. What I want is a mapped .r file to process the DOM source 
on the server side. I don't see where the JS concern.

Graham: so say your library updates . .you have to update all the 
pages that use the js libraries" . The answer is yes. The html file 
would generally behave as any other html file that is not backed 
up by any server side.

There could be a application.r file that allows for global / conditional 
page includes. What I care most is that the html file remains as 
a designer wants it - no scripting.

well, the current rsp script name may be accessible ..and if so, 
you can just load in the html page

Good. What route do I go to show the .html extension in the browser 
though?

bind-extern RSP to [.htm .j .rsp] ?

sounds like it

so your "rsp" page could be .html and the template .htm

And so I did. Then I used the app-init.r to test the results, and 
the before and after page intercept did not work.

and does rsp execute at all?

Let me check. It shou.d

It does work. Yet the example code does not inject the text before 
the </body> tag.

I mean this example code in the app-init.r: 

 on-page-start: does [
        set 'start-time now/time/precise
    ]

    on-page-end: has [pos elapsed][
        if pos: find response/buffer "</body>" [
            elapsed: now/time/precise - start-time
            insert pos reform ["<br>Processed in :" elapsed]
    ]

Doc's debug code does that ...

so the processed in no longer works with a .html extension?

Sure. But I am wrong? My understaning from the docs is that the app-init.r 
would inject this in every page when processed.

it should ....

and it does when you use a rsp extension

Don't you love it when it happens! I was working on the http.cfg 
file located in the cheyenne source rather then the proper one. I 
should've listened ot my wife an go to bed!

so, we've been chatting for 45 mins because you were working on the 
wrong file???

45 minutes? I outta go. I messed up your time.

LOL

Would you not find this web framework appealing though?