Another erb Question

ruby-talk
1

Can anyone explain the practical purpose of the final arg to ERB.new() to me?

Thanks.

James Edward Gray II

2

James Edward Gray II wrote:

Can anyone explain the practical purpose of the final arg to ERB.new() to me?

class ERB
   def initialize(str, safe_level=nil, trim_mode=nil, eoutvar='_erbout')
     ...
   end
end

You mean, +eoutvar+? That's the name of the variable that ERB uses when it generates the Ruby code that corresponds to its input. That variable will be used to build the output.

Try this:

   require 'erb'
   e = ERB.new( "One <%= ENV['HOME'] %> Two" )
   p e.src

You'll see a variable _erbout initialized to the empty string, and then the result of each operation concat'ed onto it.

- Jamis

···

--
Jamis Buck
jgb3@email.byu.edu
http://www.jamisbuck.org/jamis

3

I'm with ya to there. What would you use that for? Filling a variable of your choice with the ERB source?

James Edward Gray II

···

On Oct 27, 2004, at 4:05 PM, Jamis Buck wrote:

James Edward Gray II wrote:

Can anyone explain the practical purpose of the final arg to ERB.new() to me?

class ERB
  def initialize(str, safe_level=nil, trim_mode=nil, eoutvar='_erbout')
    ...
  end
end

You mean, +eoutvar+? That's the name of the variable that ERB uses when it generates the Ruby code that corresponds to its input. That variable will be used to build the output.

Try this:

  require 'erb'
  e = ERB.new( "One <%= ENV['HOME'] %> Two" )
  p e.src

You'll see a variable _erbout initialized to the empty string, and then the result of each operation concat'ed onto it.

4

Jamis Buck wrote:

James Edward Gray II wrote:

Can anyone explain the practical purpose of the final arg to ERB.new() to me?

[snip]

I see now that you asked about the practical purpose of that argument. :slight_smile: I ought to read messages more carefully.

I've used it in the past to allow multiple ERB instances to be run simultaneously within the same binding (ie, recursively). Without being able to change the eoutvar, each nested instance would be (ultimately) concatenating onto the same local variable, which causes grief and confusion.

- Jamis

···

--
Jamis Buck
jgb3@email.byu.edu
http://www.jamisbuck.org/jamis

5

Perhaps so you can have two independent erb runs in the same scope?

Cheers

Dave

···

On Oct 27, 2004, at 16:22, James Edward Gray II wrote:

You'll see a variable _erbout initialized to the empty string, and then the result of each operation concat'ed onto it.

I'm with ya to there. What would you use that for? Filling a variable of your choice with the ERB source?

6

My thanks to you both, Jamis and Dave.

James Edward Gray II

···

On Oct 27, 2004, at 4:25 PM, Jamis Buck wrote:

I've used it in the past to allow multiple ERB instances to be run simultaneously within the same binding (ie, recursively).

7

So, is the conclusion that puts's and print's in ERB source will go to
STDOUT? Is there a way to have their output added to the ERB result?
This seems like an important behavior to support.

Bill

···

On Thu, 28 Oct 2004 06:55:51 +0900, James Edward Gray II <james@grayproductions.net> wrote:

On Oct 27, 2004, at 4:25 PM, Jamis Buck wrote:

> I've used it in the past to allow multiple ERB instances to be run
> simultaneously within the same binding (ie, recursively).

My thanks to you both, Jamis and Dave.

James Edward Gray II

8

Concat to eoutvar? Use <%= ... %> liberally?

James Edward Gray II

···

On Oct 27, 2004, at 5:45 PM, Bill Atkins wrote:

So, is the conclusion that puts's and print's in ERB source will go to
STDOUT? Is there a way to have their output added to the ERB result?
This seems like an important behavior to support.

9

James Edward Gray II wrote:

So, is the conclusion that puts's and print's in ERB source will go to
STDOUT? Is there a way to have their output added to the ERB result?
This seems like an important behavior to support.

Concat to eoutvar? Use <%= ... %> liberally?

James Edward Gray II

I noticed this other other day while doing some testing as well, and I was quite suprised that all the documentation seemed to indicate the opposite of what it does. It at least directly conflict with the documentation in The Ruby Way, pickaxe II seems to escape by not using any examples with puts or print inside erb.

I'm not quite sure how to go about doing this, but for the scope of erb perhaps it would work better if Kernel.puts and Kernel.print were aliased to _erbout.concat (with the appropriate line ending behavior). Thus if you want debug info prepending from STDOUT you can explicitly call STDOUT.puts or STDOUT.print but otherwise I believe it should go in the right order. That or perhaps mess around with making _erbout a StringIO object instead of a string and directly aliasing to puts and print on it.

···

On Oct 27, 2004, at 5:45 PM, Bill Atkins wrote:

On a side note the commandline options to erb have a few issues. First it says:
  -d set $DBEUG to true

and also the -n modifier which is supposed to add line numbers only adds them if the source code output is set. IMHO, it should either add line numbers in both cases, or always assume -x was set.

Anyone happen to know the difference between ERB.new("text").run and ERB.new("text").result ?

Also, this has always bothered me, what is the difference between eruby and erb? Just one is a compiled C extension or is there any other reason?

Charles Comstock

10

-d set $DBEUG to true

I'm confused. What's the problem here?

Anyone happen to know the difference between ERB.new("text").run and ERB.new("text").result ?

run() simply prints the result(). Here's the source:

   def run(b=TOPLEVEL_BINDING)
     print self.result(b)
   end

Also, this has always bothered me, what is the difference between eruby and erb? Just one is a compiled C extension or is there any other reason?

erb is just a pure Ruby version of it's big brother, eRuby, according to the Pickaxe II.

James Edward Gray II

···

On Oct 28, 2004, at 3:44 AM, Charles Comstock wrote:

On a side note the commandline options to erb have a few issues. > First it says:

11

James Edward Gray II wrote:

···

On Oct 28, 2004, at 3:44 AM, Charles Comstock wrote:

On a side note the commandline options to erb have a few issues. >> First it says:
-d set $DBEUG to true

I'm confused. What's the problem here?

Well in Pickaxe 2 it says -d = set $DEBUG to true, so I'm guessing this is a spelling mistake. Doesn't really matter, but I guess it's in docs on the CLI options. I'm guessing it's actually $DEBUG, maybe that could be fixed?

Charlie

12

Egad, you're right. I totally overlooked the typo. My bad.

James Edward Gray II

···

On Oct 28, 2004, at 10:49 AM, Charles Comstock wrote:

James Edward Gray II wrote:

On Oct 28, 2004, at 3:44 AM, Charles Comstock wrote:

On a side note the commandline options to erb have a few issues. >>> First it says:
-d set $DBEUG to true

I'm confused. What's the problem here?

Well in Pickaxe 2 it says -d = set $DEBUG to true, so I'm guessing this is a spelling mistake. Doesn't really matter, but I guess it's in docs on the CLI options. I'm guessing it's actually $DEBUG, maybe that could be fixed?