World: r3wp

I've been thinking of how to separate code from display and have 
come up with the following ideas http://rebol.wik.is/Cheyenne/Page_Title/HTML_dialect


Basically the idea is to create all the html, js, css beforehand, 
and then emit in a template.  When the parser runs through the layout 
block, it builds all the CSS and JS links.  Once it reaches the body, 
it recursively parses the div tags building and closing them.  In 
the same way html, head and body tags are built and closed.

Hopefully this will result in more maintainable code .. as the whole 
page is now Rebol.  And like classical programming, we "define" all 
our variables first .. and then use them later on.

Has anyone done anything similar already?

yes, I wrote the HTML dialect to do a similar thing, though not with 
direct mapping of HTML tags to REBOL words.

I get the idea that your dialect is much more low level ...

actually it's more high level. you get loops and mapping of blocks 
and objects to tables, etc.

are you still using it?

yes, it's used on my website.

and I use it also on the R2 and R3 pages for GUI images, that I serve 
locally, as you have seen.

Have you got any examples for the pages on your sites?

I can see if I can pull a few out. The reason the HTML dialect is 
not published yet, is because the docs contain examples about redirecting, 
and coincidentally, redirects to an empty page. :-)

perhaps I can remove those parts for now...

http://www.hmkdesign.dk/rebol/html-dialect/docs/0.0.7/html-dialect.html

yes, you can use that for now.

I think I might develop my idea a little to see if I can get anywhere 
with it.

Note the docs describe version 005 to 007, whie I have 008 here.

I think what I am suggesting is a MVC approach, and so clearly the 
template at the bottom is my View, and the code at the top is the 
Model and Controller.  I imagine that it would be quite simple to 
change the View with this approach

So, in this page you could have a selection of Views ready to render 
depending on user input.

I've posted an outline of the parse rule on the same page http://rebol.wik.is/Cheyenne/Page_Title/HTML_dialect

Any parse experts care to comment ...

Rule is now working ... recurses thru the div blocks

sample template and actual ouput http://rebol.wik.is/Cheyenne/Page_Title/HTML_dialect_demo

This uses the Yahoo YUI grid t1 example

http://developer.yahoo.com/yui/examples/grids/grids-t1.html

A html dialect that builds tables and such would be used outside 
of the template.. which only does a simple substitution

Endo: I think it's possible to encap the Cheyenne server including 
RSP files, but it would require some hacking the code.

Wasn't Doc planning a virtual file system for that?

It's possible.

Henrik, is version 008 of your dialect not fully baked? What have 
you added since 007? If you could put it up on your site, I guess 
I could just diff the files to see. Also, when you say the docs describe 
005 to 007, do you mean to say that some of the docs are no longer 
relevant since they refer to the older version?

AdrianS, it's about a year since I last touched it, so I can't remember 
the details. Going to see if I can find 008 build...

thanks

http://97.107.135.89/www.hmkdesign.dk/project.rsp?id=html-dialect&page=downloads

further discussions can continue in the !HTML Dialect group

I've been thinking of how to separate code from display and have 
come up with the following ideas


I've seen much benefit when exchanging one syntax for another, especially 
when the 'other' moves away from a standard.

Very nice Graham! 

What is the final 'div for at the end of the div-rule rule?

Oops, meant to say "I haven't seen much benefit"

or just read my original post as sarcasm :0

Gregg - that final 'div rule was for debugging the rule :)

Ok, removed the 'div and fixed a few typos

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 why QM uses RSP as View only.  All the heavy lifting gets 
done elsewhere in a more familiar environment. Even with embedded 
content, it feels more like the final output.

I've looked at some php pages with js , sql etc and it just looks 
like a nightmare to maintain

That's why web devs love it so much. Job security and status as magicians

I think the term is alchemist, and not magician!

Any sufficiently complex technology is indistinguishable from magic

but one expects magic to be bug free

looks hard to maintain.


In PHP, I process/generate all the hypertext, and avoid the 'dynamic' 
aspect of web page creation altogether, so my page templates look 
like so;

<html>
<head>
<?= $cssincludes ?> // CSS
<?= $headincludes?> // JQuery, specific javascript functions  
</head>
<body>
<?= $body ?>
</body>
</html>

That's pseudo.. in reality, I have column definitions for templating 

<?

$var1 = "Column 1";
$var2 = "Column 2";
$var3 = "Column 3";

$c1.= "<div>$var1</div>";
$c2.= "<div>$var2</div>";
$c3.= "<div>$var3</div>";

//Column widths can be modified dynamically or set initially
<style>
#c1{
width: 50%;
}
#c2{
width: 25%
}
#c3{
width: 25%  
}

</style>

?>

<html>
<head>
</head>
<body>
  <div id="content">
  <div id="c1">
  <?=$c1?>
  </div>
  <div id="c2">
  <?=$c2?>
  </div>
  <div id="c3">
  <?=$c3?>
  </div>
</body>
</html>

A simple 3 column template handles 97% of my needs

As long as you have just simple pages, it's fine. You can use this 
with RSP easily as well.. but if you want to look at "hard to maintain" 
PHP code.. and have good nerves..just download Magento's sources 
and try to figure out what's going on.

This is a little odd .... I created a PDF and sent it back to the 
browser using the response, and application pdf, and the browser's 
security prevents it from downloading ....on some of the user's PC's 
( at a hospital ), but if I write the pdf to the disk and then redirect 
the browser to the file in the www directory, there's no complaint!

so, the browser is treating a PDF differently that is being sent 
directly via the response, as opposed to fetching the PDF using GET