World: r3wp

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?

not me ...

ie. I'd like to see it working first

it looks more higher maintenance than what I had in mind

Well... I am going to find out what a good night sleep does.

You say so because in your dialect, the master of the page is yourself. 
What do you do though when you have to interract with web designers?

give them the template I guess

The re-usability that you are looking for (i.e. the JS, etc) could 
be met with a simple configuration file and page fragements.

In my idea, the template would be loaded from DB .. so it could be 
altered on a per user basis

Besides, CSS would take care of most cases of re-use.

Having a single template does not appeal

but .. show me the pudding and I'll eat it :)

:) We need to write some code then. See ya. And thanks for the time.

bye

Florin, Gabriele wrote a templating engine based on XML ID attributes 
several years ago. It's called Temple

I agree with your requirement of designer-approachable templates

Most other REBOL engines you'll find are based on the reverse concept 
of wanting to make as much as possible into REBOL syntax

Kaj, thanks. I will look for it.

Well, half hour google search does not help finding it.

Does anyone have a busy httpd.cfg to share? Trying to learn from 
some practical examples.

I don't think I've ever seen Temple

I don't find much use of rebol view. I'm interested in browser based 
stuff, and that's the only way I'd spend time with rebol. I'd love 
to take a look at Temple.

I believe this is what you are looking for - http://www.rebol.it/giesse/temple.r

I found it by searching the mailing list archives at rebol.org

This recorded AltME discussion seems to serve as documentation - 
http://www.rebol.it/giesse/Temple.pdf

Wonderful. I'm going to look into it.

I read the conversation. That is what I am looking for. Unfortunatelly, 
it was anandoned. Temple is not using Cheyenee but cgi.

Graham: It appears that this could be some proof in the puding. Andrew 
has few concerns that seemed to be much like yours. Interesting read. 
I wish I came accross this type of framework when I was still doing 
Struts in 2003.

temple is pre-cheyenne