World: r3wp

It's Latin for "look above", or, read what was written before.

ok, thanks - now my questions - Chayanee with RSP and Magic!  are 
two different products, right?

RSP and magic are completely different products, yes.  Same idea, 
but differente everything else.

which one works with "custom tagging"? That wins for me - no mixture 
of rebol plus html code plese :-)

<but does anyone know what happened to Shlik?>

Not. His website changed a couple of times. Last known (to me) working 
one was
  http://laurentchevalier.dyndns.org/rebol/
But that is broken now.

RSP was/is much more like PHP  -- rebol code embedded in HTML tags.
That's probably the one you''d prefer, Petr.

or maybe I misread your preference -- Magic is more like a HTML-generating 
dialect

not sure .... but I will know very soon now - finishing some databases 
for my friend, I will let designer do his work and produce some templates. 
Those templates have to be displayable without touching rebol ...

so maybe magic ...

nor Magic! is the way to go for me, as I look into it now :-)

you should invent the best notation then :-)

what do you mean by notation? :-) I already said that I preferred 
Temple way to go. Simply put - I am not designer, my designer is 
not a coder. So I want him to freely produce his "magic ui wonders",using 
his tools, not being dependant upon rebol. So I assume we go with 
maybe slower aproach - html with comment sections, parsed by rebol, 
replaced by engine ...

ah, now I remember another one - Maxim's Remark, but it was probably 
not released either ...

Max sent me a copy of ReMark.

how would the the designer like to do the markup? inserting html-tags? 
inserting a demo-table with data? what do his tools support?

yes, exactly, have you looked at Gabriele's temple? More in 20 min, 
got to go ...

Hello, there is also FastMagic!, a refactoring of Magic! to work 
in FastCGI mode... It also add some usefeull tags like <rebol:include> 
<rebol:if>, <rebol:forall> and <rebol:make-doc-pro>. Rebol Directory 
is being developped with it and the code is available at d2740.servadmin.com/~francois/. 
You will find both fastmagic! code and the code of Rebol Directory 
as well...

And you can switch from FastCGI to CGI but modifying the flag mod-fastcgi 
in the file fmagic.r

You can also add custom tag by extending the engine: 'm-execute. 
This is how I added <rebol:xxx> tags, because I want to avaide my 
html page to look like plain cgi scripts...

The problem is I did not use such system in praxe, so maybe I develop 
it on my own (very simple first version) to actually better understand 
needs of the cooperation between me and our designer ... then I can 
eventually choose one which fits best ....

Maybe the designer could make own suggestions? Making a demo-page 
where he marks up in a way he would like. And we figure out how to 
translate that in a parsert.

now let me explain how Temple works ... if I screw it, maybe Gabriele 
will correct me :-)

It works like a DOM. It decomposes (parses) html page (disadvantage 
is it requires tags to be properly ended, but that is maybe question 
of robustness of parsing mechanism, which just could be made better) 
into rebol block ....

you simply don't put ANY tags into your page ... you simply use advantage 
of 'class and 'id elements, where 'id is unique identifier, e.g. 
table number, and 'class is simply a class :-) - repetitive object 
of some kind (e.g. column)

maybe parsing could be done with a prefix-tag. 
 <fill-data><tabel> ... </table>

and the parser figures out where the next tag (the table here) ends.

then you have several functions available, mainly find-by-id, find-by-class, 
find-path (which help you in nesting into parsed block-of-blocks 
structure ....

and there is the main function temple-map-data, which in combination 
with above functions finds particular element (e.g. table) and in 
repetitive manner maps data into structure - it replaces those elements 
...

so - my deisnger e.g. does table, assigns it 'id or not, does e.g. 
two rows as an example of the design, and via temple-map-data you 
map it ....

sounds smart. (forget that prefix-thing, typed before reading about 
id)

no mixture of data and code, aproach, which should go into trashcan 
;-) It was imo developed by by php freaks, who do both - design and 
coding. Such stuff is not able to work unless you put it into production 
environment ...

Of course Temple imposes certain kind of web development, but ....

sounds like its the way to go fo you. lets try it :)

IIRC even Doc liked it (he has that WEbsomething tool)

i guess php goes another way. its simple enough for designers to 
php themself. means real pro designers would not. but most "hobbiists" 
can, not only freaks.

Gabriele just admitted, it can be slow ... you simply has template.html 
- your designer is completly free to replace it not knowing single 
line of REBOL, then you have your engine - temple, and then your 
temple script (those map-data find-by-class etc. instructions)

maybe kind of caching could be introduced to speed things, not needing 
to parse template with each request ...

often those things can be speedd upby caching/compiling. You parse 
the pagew, store this find-by-class data in a file and use that on 
request.

the thing I really don't like is - original html code structure (pretty 
formatting is lost), as html code is generated back from "DOM" (rebol 
blocks of blocks) ... I don't like it, but well, otherwise you would 
have to remember original position in original html template and 
things could become tricky ...

same idea, same time typing :)

yes :-) I really found temple being kind of different of other templating 
systems and being really smart ....

No, you could store the html-parts in the blocks to. could keep formating. 
more like indexing the original to know insert-positions.

there is just that one thing of code formatting - so simply don't 
look at html source :-)

As long as the rebol-source is ok :) do you have a link?

ask Gabrile - he sent me one version one and a half year ago privately 
- dunno if there was any developement or not ....

I also wonder what is ReMark about, but it will be tagging too .... 
as I said - I will try similar aproach to Temple ... and the concept 
sounds really cool, maybe it would be worth to start it under the 
Ashley's wings :-), as RebDB and RebGUI - so documented from the 
beginning, etc :-)

Good idea. Ashley is kind of Carl for the open-source-part :)

you can insert formatting just by inserting something like "^/" etc., 
just it is usually not worth doing. other than that, Temple preserves 
the original formatting from the template.

How does Template oriented development fit for application with complex 
authorization roles? I mean application where users can be in different 
department with different roles, like a CRM tool?

Gabriele - that was not critique, just a note about what actually 
I did not like ... but who looks into html source anyway? :-)

Those users access the same template, but the content can vary according 
to what they can see or not