Ask a Question related to Ruby, Design and Development.
-
John W. Long #1
HTML Generation (Next Generation CGI)
Hi,
This idea for the next generation of CGI has me thinking (see
[url]http://rubygarden.org/ruby?NextGenerationCGI[/url]). It seems that CGI would be
best if it were broken in two. One side handled generating html, and the
other handled all the other stuff (params, headers, etc...).
Last night I started prototyping some of my ideas and came up with the
following:
class HtmlGenerator
def render(klass, &blk)
hg = klass.new
hg.render(&blk)
end
end
class Html4
attr_accessor :encoding
def render(&blk)
"<html>#{self.instance_eval(&blk)}\n</html>"
end
def head(&blk)
"\n<head>#{self.instance_eval(&blk)}\n</head>"
end
def title(&blk)
"\n<title>#{self.instance_eval(&blk)}</title>"
end
def meta(hash = {})
"\n" + '<meta name="' + hash[:name] + '" content="' + hash[:content] +
'">'
end
def body(&blk)
"\n<body>#{self.instance_eval(&blk)}\n</body>"
end
def h1(&blk)
"\n<h1>#{self.instance_eval(&blk)}</h1>"
end
def h2(&blk)
"\n<h2>#{self.instance_eval(&blk)}</h2>"
end
def p(&blk)
"\n<p>#{self.instance_eval(&blk)}</p>"
end
def b(&blk)
"<b>#{self.instance_eval(&blk)}</b>"
end
def i(&blk)
"<i>#{self.instance_eval(&blk)}</i>"
end
end
hg = HtmlGenerator.new
puts hg.render(Html4) {
encoding = "US/English"
head {
title { "My Document" } +
meta(:name => "description", :content => "this is a description of this
document")
} +
body {
h1 { "Heading 1" } +
p { "A small paragraph." } +
h2 { "Heading 2" } +
p { b { "Bold" } + " " + i { "Italic" } }
}
}
I like the syntax of this very much, but I would like input on two things.
The first this would require heavy use of instance_eval. Would this be a
good thing? It strikes me that the main problem with instance_eval is that
you can begin to change the interface of the class. However, as this is
implemented above you can see that changes to the implementation would only
effect an instance of the HtmlXX class, which would go into never never land
as soon as the render call is completed.
The second, a bit harder, I would like to remove the need for the pluses in
order to chain the results together. Any Ruby gurus that would like to try
and take a stab at it? I can think of one possible solution, but I'm not
sure if the results would really be satisfactory.
--
John Long
contact me through: [url]www.wiseheartdesign.com[/url]
John W. Long Guest
-
PDF Generation Using ver 7
Hi I have an existing code that silently generates pdfs by supplying file path and printing to "Acrobat PDFWriter", but it's using Acrobat ver 5.... -
CF5 + XML generation
Hi, I'm trying to create an XML file from pulled data in our DB. I don't know if I'm doing this the right way. Maybe someone can show me a... -
Key Generation
Is it at all possible to generate contribute keys on the fly? without using the Contribute software? We have well over 100 customers who use the... -
HTML generation
Is there a list of all the different ways of outputting HTML in Ruby somewhere? I can think of using the "puts" statement, eRuby, and CGI. Any... -
HTML file generation from PHP scripts
Thanks for the suggestion guys, but I did forget an important detail. I do not have access to a unix shell so the whole thing must be... -
Mauricio Fernández #2 Re: HTML Generation (Next Generation CGI)
On Sun, Nov 23, 2003 at 01:50:29AM +0900, John W. Long wrote:
[...]> Last night I started prototyping some of my ideas and came up with the
> following:You can use a technique similar to flgr's Junction or oGMo's criteria to build a> hg = HtmlGenerator.new
> puts hg.render(Html4) {
> encoding = "US/English"
> head {
> title { "My Document" } +
> meta(:name => "description", :content => "this is a description of this
> document")
> } +
> body {
> h1 { "Heading 1" } +
> p { "A small paragraph." } +
> h2 { "Heading 2" } +
> p { b { "Bold" } + " " + i { "Italic" } }
> }
> }
"parse tree".
What would be really cool would be taking a DTD and generating the Ruby
code from that that validates the document as it is built.
It would be possible to define how blocks can be nested, etc, in
practice, ensuring that no illegal sequence of calls is made.
--
_ _
| |__ __ _| |_ ___ _ __ ___ __ _ _ __
| '_ \ / _` | __/ __| '_ ` _ \ / _` | '_ \
| |_) | (_| | |_\__ \ | | | | | (_| | | | |
|_.__/ \__,_|\__|___/_| |_| |_|\__,_|_| |_|
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com
Are Linux users lemmings collectively jumping off of the cliff of
reliable, well-engineered commercial software?
-- Matt Welsh
Mauricio Fernández Guest
-
Ara.T.Howard #3 Re: HTML Generation (Next Generation CGI)
On Sun, 23 Nov 2003, Mauricio Fernández wrote:
what advantage would this give over:> Date: Sun, 23 Nov 2003 18:19:56 +0900
> From: Mauricio Fernández <batsman.geo@yahoo.com>
> Newsgroups: comp.lang.ruby
> Subject: Re: HTML Generation (Next Generation CGI)
>
> On Sun, Nov 23, 2003 at 01:50:29AM +0900, John W. Long wrote:> [...]> > Last night I started prototyping some of my ideas and came up with the
> > following:> > hg = HtmlGenerator.new
> > puts hg.render(Html4) {
> > encoding = "US/English"
> > head {
> > title { "My Document" } +
> > meta(:name => "description", :content => "this is a description of this
> > document")
> > } +
> > body {
> > h1 { "Heading 1" } +
> > p { "A small paragraph." } +
> > h2 { "Heading 2" } +
> > p { b { "Bold" } + " " + i { "Italic" } }
> > }
> > }
~ > cat bar.rb
require 'amrita/template'
template = Amrita::TemplateText.new <<-html
<html>
<head><title id=title></title><meta id=meta/></head>
<body>
<h1 id=h1></h1> <p></p> <h2 id=h2></h2>
<p> <b id=b></b> <i id=i></i> </p>
</body>
</html>
html
data = Hash[
:title => 'My Document',
:meta => Amrita::a(:name => 'description'){'this is a description of this document'},
:h1 => 'Heading 1',
:p => 'A small paragraph',
:h2 => 'Heading 2',
:b => 'Bold',
:i => 'Italic',
]
template.expand STDOUT, data
~ > ruby bar.rb
<html>
<head><title>My Document</title><meta></head>
<body>
<h1>Heading 1</h1> <p></p> <h2>Heading 2</h2>
<p> <b>Bold</b> <i>Italic</i> </p>
</body>
</html>
~ > cat foo.rb> You can use a technique similar to flgr's Junction or oGMo's criteria to build a
> "parse tree".
>
> What would be really cool would be taking a DTD and generating the Ruby
> code from that that validates the document as it is built.
> It would be possible to define how blocks can be nested, etc, in
> practice, ensuring that no illegal sequence of calls is made.
require 'amrita/template'
template = Amrita::TemplateText.new <<-html
<table>
<b>
<tr id=row><td id=a/><td id=b/></tr>
</b>
</table>
html
data = Hash.new[ :row => {:a => 'illegal', :b => 'row'} ]
template.expand STDOUT, data
~ > ruby foo.rb
/data/ruby-1.8.0//lib/ruby/site_ruby/1.8/amrita/parser.rb:304:in `parse': error hapend in :2(<tr> can't be in <b>) (Amrita::HtmlParseError)
==>><td id=a/><td id=b/></tr>
</b>
</table>
from /data/ruby-1.8.0//lib/ruby/site_ruby/1.8/amrita/parser.rb:269:in `parse_text'
from /data/ruby-1.8.0//lib/ruby/site_ruby/1.8/amrita/template.rb:405:in `load_template'
from /data/ruby-1.8.0//lib/ruby/site_ruby/1.8/amrita/template.rb:208:in `setup_template'
from /data/ruby-1.8.0//lib/ruby/site_ruby/1.8/amrita/template.rb:115:in `expand'
from foo.rb:10
amrita is pretty hard to beat. at the very lest, it could be built on. it's
handling of array's make generating complex pages very easy:
~ > cat foobar.rb
require 'amrita/template'
template = Amrita::TemplateText.new <<-html
<html>
<body>
<table>
<tr id=rows><td id=name></td><td id=ssn></td></tr>
</table>
</body>
</html>
html
data = Hash[
:rows => [
{:name => 'joe', :ssn => '574-86-3205'},
{:name => 'bob', :ssn => '572-84-8964'},
# imagine there are _many_ of these
]
]
template.expand STDOUT, data
~ > ruby foobar.rb
<html>
<body>
<table>
<tr><td>joe</td><td>574-86-3205</td></tr><tr><td>bob</td><td>572-84-8964</td></tr>
</table>
</body>
</html>
it will hard to beat amrita's handling of nested data structures. another
thing that is really good about it is that it separated html from cgi logic.
that way to can say "don't like how it looks?, here's the template - add
something" to your web designers.
anyhow, amrita is worth checking out.
-a
--
ATTN: please update your address books with address below!
================================================== =============================
| EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
| PHONE :: 303.497.6469
| ADDRESS :: E/GC2 325 Broadway, Boulder, CO 80305-3328
| STP :: [url]http://www.ngdc.noaa.gov/stp/[/url]
| NGDC :: [url]http://www.ngdc.noaa.gov/[/url]
| NESDIS :: [url]http://www.nesdis.noaa.gov/[/url]
| NOAA :: [url]http://www.noaa.gov/[/url]
| US DOC :: [url]http://www.commerce.gov/[/url]
|
| The difference between art and science is that science is what we
| understand well enough to explain to a computer.
| Art is everything else.
| -- Donald Knuth, "Discover"
|
| /bin/sh -c 'for l in ruby perl;do $l -e "print \"\x3a\x2d\x29\x0a\"";done'
================================================== =============================
Ara.T.Howard Guest
-
John W. Long #4 Re: HTML Generation (Next Generation CGI)
> You can use a technique similar to flgr's Junction or oGMo's criteria to
build aI'm not familiar with either library. How would you see a parse tree helping> "parse tree".
in this situation?
Honestly I don't think it would be that hard to do. The hairiness of the> What would be really cool would be taking a DTD and generating the Ruby
> code from that that validates the document as it is built.
> It would be possible to define how blocks can be nested, etc, in
> practice, ensuring that no illegal sequence of calls is made.
project would be understanding the finer points of dtd. Simply creating a
generator object with a smart method_missing shouldn't be that hard. This
object could then recursively create other generator objects that contain
the appropriate subset of the dtd for the section of the document you are
working on.
--
John Long
[url]http://wiseheartdesign.com[/url]
John W. Long Guest
-
John W. Long #5 Re: HTML Generation (Next Generation CGI)
> -- Ara Howard wrote: --
<snip amrita stuff here />> what advantage would this give over:
Actually I have used Amrita. And yes Amrita is a good library. I think it
will be even better after it gets some of the kinks worked out of it. (Maybe
it already has. I last looked at Amrita in the spring.)
I'm not so interested in creating a template library. CGI currently has the
kind of functionality I suggested. Personally I'm not sure I would
personally use it, but it does meet another need. It can generate HTML code
in several different flavors. From HTML3 - XHTML transitional if I remember
right. This is kind of a neat idea, although as I said I'm not totally sure
I would use it myself.
--
John Long
[url]http://wiseheartdesign.com[/url]
John W. Long Guest
Reply With QuoteSimilar Questions and Discussions
Posting Permissions
- You may not post new threads
- You may post replies
- You may not post attachments
- You may not edit your posts
