Professional Web Applications Themes

HTML Generation (Next Generation CGI) - Ruby

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] ...

  1. #1

    Default 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 Doent" } +
    meta(:name => "description", :content => "this is a description of this
    doent")
    } +
    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

  2. #2

    Default 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 Doent" } +
    > meta(:name => "description", :content => "this is a description of this
    > doent")
    > } +
    > body {
    > h1 { "Heading 1" } +
    > p { "A small paragraph." } +
    > h2 { "Heading 2" } +
    > p { b { "Bold" } + " " + i { "Italic" } }
    > }
    > }
    You can use a technique similar to flgr's Junction or oGMo's criteria to build a
    "p tree".

    What would be really cool would be taking a DTD and generating the Ruby
    code from that that validates the doent 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

  3. #3

    Default Re: HTML Generation (Next Generation CGI)

    On Sun, 23 Nov 2003, Mauricio Fernández wrote:
    > Date: Sun, 23 Nov 2003 18:19:56 +0900
    > From: Mauricio Fernández <batsman.geo>
    > 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 Doent" } +
    > > meta(:name => "description", :content => "this is a description of this
    > > doent")
    > > } +
    > > body {
    > > h1 { "Heading 1" } +
    > > p { "A small paragraph." } +
    > > h2 { "Heading 2" } +
    > > p { b { "Bold" } + " " + i { "Italic" } }
    > > }
    > > }
    what advantage would this give over:

    ~ > 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 Doent',
    :meta => Amrita::a(:name => 'description'){'this is a description of this doent'},
    :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 Doent</title><meta></head>
    <body>
    <h1>Heading 1</h1> <p></p> <h2>Heading 2</h2>
    <p> <b>Bold</b> <i>Italic</i> </p>
    </body>
    </html>
    > You can use a technique similar to flgr's Junction or oGMo's criteria to build a
    > "p tree".
    >
    > What would be really cool would be taking a DTD and generating the Ruby
    > code from that that validates the doent 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.
    ~ > cat foo.rb

    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/pr.rb:304:in `p': error hapend in :2(<tr> can't be in <b>) (Amrita::HtmlPError)

    ==>><td id=a/><td id=b/></tr>
    </b>
    </table>
    from /data/ruby-1.8.0//lib/ruby/site_ruby/1.8/amrita/pr.rb:269:in `p_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

  4. #4

    Default Re: HTML Generation (Next Generation CGI)

    > You can use a technique similar to flgr's Junction or oGMo's criteria to
    build a
    > "p tree".
    I'm not familiar with either library. How would you see a p tree helping
    in this situation?
    > What would be really cool would be taking a DTD and generating the Ruby
    > code from that that validates the doent 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.
    Honestly I don't think it would be that hard to do. The hairiness of the
    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 doent you are
    working on.

    --
    John Long
    [url]http://wiseheartdesign.com[/url]




    John W. Long Guest

  5. #5

    Default Re: HTML Generation (Next Generation CGI)

    > -- Ara Howard wrote: --
    > what advantage would this give over:
    <snip amrita stuff here />

    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

Similar Threads

  1. PDF Generation Using ver 7
    By maxcontrol in forum Adobe Acrobat SDK
    Replies: 0
    Last Post: September 29th, 02:54 PM
  2. CF5 + XML generation
    By Loony2nz in forum Coldfusion - Advanced Techniques
    Replies: 0
    Last Post: June 28th, 12:45 AM
  3. Key Generation
    By RobCurry in forum Macromedia Contribute General Discussion
    Replies: 1
    Last Post: April 15th, 02:32 PM
  4. HTML generation
    By Philip Mak in forum Ruby
    Replies: 14
    Last Post: September 17th, 05:43 PM
  5. HTML file generation from PHP scripts
    By Emanuele D'Arrigo in forum PHP Development
    Replies: 6
    Last Post: July 18th, 09:34 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139