World: r3wp

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?

For those interested in info on Maxim's Remark   http://www.rebol.it/~steel/retools/remark/index.html.
 Looks like you need to contact him privately for a copy of it.

magic! is here:
http://www.rebolfrance.org/
docs in english here:
 http://www.compkarori.com/vanilla/display/Magic%21

Thanks Sunanda

Francois - I accept your explanation of Magic's concept only in the 
case, if designer can upload different template without me (the developer) 
needing to edit it .... but I may be not so strict :-) I will look 
into Magic's english docs - french docs are really a problem for 
me ...

James Nak - FastMagic! is there www.rebolgique.net, as well as the 
code of the Web application Rebol Directory, which i think is kind 
of a good way to learn Magic! and FastMagic!

Mercí François.

What is the difference between Magic! and FastMagic! ?

Magic! is CGI
FastMagic! is FastCGI

Ah.

François, thanks, I was already wondering how hard it would be to 
scale up Magic! with FastCGI. Do you have any idea how many users 
FastMagic! could serve?

Kaj, it depends on how many FCgiServer you define. The more you define, 
the more concurrent requests you can serve. But be carrefull: many 
FCgiServer means many open db connections, which needs more resources. 
FastMagic! keeps in cache applications and db connection. Indeed, 
opening a connection is time consumming as well reading files on 
the drive...

With Cheyenne, I share a single db connection with all instances, 
and keep it open all the time.

This is interesting indeed, but this means you can serve one resquest 
at a time... But I guess it would be easy to manage a pool of connection. 
Where is cheyenne available? I would like to adapt FastMagic! on 
it with a DB pool and use it for the Rebol Directory

Francois - that is not true - you can hold just one db connection 
;-) FastCGI is nothing but advantage :-) you simply can use code 
like following to check if you have already opened connection ... 
exists-conn?: false .... if not exists-conn? [open-your-db-connection-here 
exists-conn?: true]

of course if only one channel to db exists, you have to come-up with 
request serialisation, or siply for each request you can open new 
data channel, no?

db: open mysql://user:[pass-:-domain-:-com]/database-schema
data-channel1: first db
data-channel2: first db

but - I just tried that with mySQL driver and it does not work :-( 
.... it works that way with /Command though ... it is a pity there 
is not multiple command ports available in Doc's driver?

Yes Pekr, but Rebol is not multithreaded, so to have multithreading, 
you must lauch multiple Rebol VM as FastCGIServer. How do you manage 
the different VM to communicate?

All right, you were talking about Cheyenne. So were is it?

you don't always need multithreading ... if you do clever multiplexing 
...

http://www.softinnov.org- try that for Cheyenne ...

from dockimbel

http://softinnov.org/rebol/uniserve.shtmlProducts link in left 
navigation area.

left nav area is standard on all pages actually, so Pekr's link would 
do  ;)

From evaluating the documentation, I thought that Magic! doesn't 
necessarily need an SQL database? Does FastMagic! require one?

quick question on Magic and FastMagic.

I understand that FastMagic supports FastCGI.


Is there any difference between the requirements? Does FastMagic 
requires /cmd  or just /core?

where can I find more info. on FastMagic

Only /Command has FastCGI built in. AKAIK, there is no complete implementation 
of FastCGI for /Core. When last I heard, development of one was stopped 
voluntarily to avoid devaluing /Command.

Given that, a REBOL language version of FastCGI would probably have 
to work differently, and FastMagic would then need a little recoding 
to work with it.

Whoops, not "AKAIK", "As far as I know" (AFAIK).

Kaj, FastMagic! does not require SQL database. But it does require 
Rebol/Command and Linux. Indeed, FastCGI in CGI compatibility mode 
needs a POSIX environment. Nevertheless, you can use FastMagic! in 
normal CGI mode, by setting the flag mod-fastcgi to false (in the 
fmagic.r file). Actually, i develop under windows in CGI mode and 
deply under Linux in FastCGI mode, and it workds well. I tried to 
be as much compatible as possible with the original Magic!. Again, 
the application code for Rebol Directory is definitly the best way 
to learn how to develop with (Fast)Magic! You can download it at 
www.rebolgique.org

Yeksoon, there is no formal documentation yet for FastMagic!, but 
the code for the web application using FastMagic is available on 
www.rebolgique.org

Mozilla and XML standards support - http://www-128.ibm.com/developerworks/xml/library/x-ffox15.html?ca=dgr-lnxw07FirefoxXML