RCR to modify #puts and #print inside ERB

[Jay Levitt]

I'm getting the idea that the people on each side of this discussion
disagree because they have different mental models of what ERB does,
and what a ERB document is:

1. ERB just implements very fancy, flexible, string interpolation.
or
2. ERB documents are executable code (actual programs), where text
prints itself, and code blocks get run.

Excellent summary. As someone who came from neither PHP nor JSP (PL/I,
if you must know), and whose first exposure to ERB was Rails, my mental
model is #2, even though deep down I know it's actually implemented as
#1. Which is why "puts" outputting to the doc, not stdout, is the non-
anomalous (omalous?) behavior to my mind.

 

[Lyndon Samson]

------=_Part_7410_10252724.1126482136142
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

=20
One could capture the output by setting the default output to a
StringIO; this is similar to what I did in a previous solution. It is
rather easy to put together a simple, thread-safe version that does
this. Currently, the default is to capture the output as a string, but
a webserver-related use would probably just send the output directly
to the browser *as it is being output*, rather than building the
string and sending it all at once.
=20
I don't see this as being about adding "magic" to the implementation.
If you are of the mindset that the template is concatting to a string,
the puts idea doesn't make sense; but if you see it as printing to an
output stream (with the whole _erbout thing just being an
implementation issue), then the lack of a working print/puts is what
doesn't make sense.
=20
=20

Indeed, their are certain efficiencies not having to pre-generate all outpu=
t=20
before transmission. Think file downloads, dynamic image generation etc.

As a general tool, being able to reassign STDOUT/STDIN/STDERR to an IO woul=
d=20
be very powerfull.=20

From my perspective, ERB's main usage is as a dynamic web page generator=20
means that its natural to think of all program output going 'to a web=20
browser' rather than to a console.

------=_Part_7410_10252724.1126482136142--

 

[David A. Black]

Hi --

Hi,



That's the thing; to those of us who don't see it as just "fancy
string interpolation", the *current* behavior is anomalous, not the
suggested behavior. The current behavior actually seems rather magic,
until you discover why it behaves that way, after which it just feels
poorly implemented.

When a method is called in a <%= %> block, that part of the template
gets filled in with a string representation of its return value. This
behavior, as far as I know, is consistent across all method calls. If
any one or two methods get special treatment, that's an anomaly (or
exception, or special case, or whatever). That's all I mean. There
is *already* a technical principle at work.

[...]

I don't see this as being about adding "magic" to the implementation.
If you are of the mindset that the template is concatting to a string,
the puts idea doesn't make sense; but if you see it as printing to an
output stream (with the whole _erbout thing just being an
implementation issue), then the lack of a working print/puts is what
doesn't make sense.

If you decide a priori that ERB is a failed implementation of
something other than itself, rather than a successful implementation
of what it actually is, then of course you will conclude that it needs
to be changed But I don't know of any reason to think that the
_erbout design is a failed implementation of an output stream, rather
than a successful implementation of a string buffer. (It's more than
possible that I'm not familiar with all the past discussions and
statements from the author(s) though.)

In any case, I think the wind-up toy has hit the wall, and I'd like to
turn it around so it can keep moving. I guess the main thing I'd like
to see, if ERB is to gain a way to do the kind of streaming you're
describing, would be for it to happen without loss: that is, without
loss of consistency (don't just shoehorn the behavior into methods
that already have a clearly defined behavior) and without loss of
functionality (make sure that stringwise template-filling is not
discarded or made difficult).


David

 

[Paul Brannan]

Proposed RCR:

Modify ERB so that calls to #puts, #print, and #p inside the template
append the resulting string onto the local ERB output variable,
instead of sending the output to $stdout. #warn would still send to
STDERR (for debug messages seen but kept out of the result string)
and $stdout#<< could also be used.

Why not just change $stdout, e.g.:

<%
require 'stringio'
$orig_stdout = $stdout
$stdout = StringIO.new(_erbout, 'a')
$stdout.sync = true
%>1
<% puts "2" %>3
<% $stdout = $orig_stdout %>

should print:

1
2
3

Then puts keeps the same behavior as it has now, and you get the result
you want using the existing behavior.

Paul

 

[Gavin Kistner]

--Apple-Mail-3-742888928
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=US-ASCII;
delsp=yes;
format=flowed

Why not just change $stdout, e.g.:

<%
require 'stringio'
$orig_stdout = $stdout
$stdout = StringIO.new(_erbout, 'a')
$stdout.sync = true
%>1
<% puts "2" %>3
<% $stdout = $orig_stdout %>

should print:

1
2
3

Then puts keeps the same behavior as it has now, and you get the
result
you want using the existing behavior.

If you're suggesting putting this at the top of every ERB template,
then that's the reason not to do it. The purpose of this idea (which
I've mostly abandoned, seeing how many are against it) was to make
puts and print "just work", so that you don't have to think of ERB as
different from any other ruby program. The above certainly provides a
way for puts and print to work, but it requires too much effort.
--Apple-Mail-3-742888928--