World: r3wp

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

I expect Temple being on-hold for quite some time, right? I have 
some 0.1 version from last January ...

I feel that there will be an explosion of id/class combination

and how is it done with other systems?

francois: Temple can match any tag. not just by id and class, but 
by name or any attribute.

look, if you are about to fill-in - name, last-name, address, age, 
it will be the same for old ppl. The decision - what info to whom 
is imo db related, so imo as a result of a query you should already 
obtain only relevant recordset - why should that be messed into logic 
of templating system?

old ppl = all ppl :-)

what you'd do in your case is have a template with everything in, 
and the code selects what to show. from the point of view of the 
code, you just have abstract entities ("login form", "list of accounts", 
"list of messages" and so on) and you habdle that. how they are implemented 
in HTML is not something you need to worry about, except in some 
rare cases or when you are in a hurry and do QAD things ;)

or you mean e.g. not displaying 'price to ppl outside of sales department? 
It can be imo done with db logic once again, or simply your template 
engine could take care for that ...

it is long time ago I looked into Temple - did not remember you can 
find also by name etc. options ....

Well, i see your ponts, but the application logic regarding security 
and authorisation will be linked to the template: suppose i have 
a page with different section: some section are visible by me and 
other by my colleague only and other by both, the template, through 
ids, classes, etc must tell the application what data must be retreived... 
So the web designer must know something about the logic, no?

With magic, you can do that by nesting the section into a <rebol:if 
...>

And i feel this is not more complicated than playing with templates 
and exceptions on templates, but I may be wrong, as I never try template 
with such authorisation logic.

OK, and if your designer puts custome <rebol:if...> tag into his 
template, how is that reflected in his webtool? Does it distorts 
his display, or do those tools ignore such custom tags?

I am not agains customs tag - in fact, I thought about mixture of 
such tags and temple aproach. I simply require 1) designer not needing 
to know single line of rebol code 2) whatever he does, needs to be 
consistently visible without the upload to production environment 
...

DocKimbel once told me (or someone else, don't remember now :-), 
that DreamWeaver worked with such "code modules" like you would write 
for temple, and those were represented by config dialog in DreamWeaver. 
So, you can "customise" how your script will behave, it is put inside 
comment tags (or other special tags), so that display is not affected 
in DreamWeaver ...

e.g. - look at http://www.rebol.com/docs/cgi2.html- such aproach 
where html code is generated by script is absolutly unacceptable 
for me - I am strict about it, unless someone proves me being wrong 
:-)

i like that junction-idea with server-side javascript :)

junction?

oops, wrong group.

Was taling privately. http://trimpath.com/project/wiki/TrimJunction

Pekr, I agree with you with pure cgi. Coding like that is from old 
days. But I think that Magic! (and FastMagic!) is a kind of mix between 
tamplate and rebol code. You can achieve good interaction with your 
web designer: have a look at the code of Rebol Directory: All rhtml 
pages starts with rebol codes, and then come the html. In the html 
section , there is not a single piece of application logic, except 
those specific for presentation (<rebol:if...>, etc...) So the idea 
is: your web designer provides you with the html and you just add 
the pure rebol code, without polluting the html sections. The design 
might change, but not the content, therfore, you web designer can 
modifier the rhtml, and the rebol codeur has nothing to do.

And that's what we like - nothing to do :)

you are right, this is why rebol is cool: so much less to do than 
other languages

:)

The template is how the page should look. if you have different looks 
for different users, they're probably better being different templates.

the HTML disigner *WILL* have to know what is going to be on the 
screen. of course, he don't need to know that exaclty - a table can 
have as many columns and rows as you need. that's still a table.

Where is Magic! available?