Re: Leading/trailing newlines

>It would be expensive, but I'm not sure it'd be _too_ expensive.

Well if it really was, what about having the default being 'never' 
(with no overrides allowed) and using the lazy function definition 
pattern (sorry, don't know what it's called in Perl) to return an 
anonymous sub that redefines the relevant bit to match the 
user-chosen default behaviour?

Though as it's just checking 2 hash values (directly rather than 
through the api) and then doing a simple substitution, I would have 
thought that paled into insignifance compared to  the overhead of 
actually calling the component in the first place.

>However, if the goal is to provide a feature similar to what TT provides
>for controlling newlines/whitespace _around template directives_, then it
>should be done at compile time only.

OK. I'm just throwing it out there, you know.... Stirring what's on 
the back burner.

>What Alex was describing would affect all the output, including the output
>from interpolated variables/functions/etc. I think this would be too much
>for most people.

But it would only apply to component calls. How would it affect 
interpolated variables? As for functions, I'm not clear as to what 
you mean (my bad, not yours ;). My proposed solution, targets 
components pure and simple (be they regular components, top level 
components or def or method components). I don't see what else would 
get affected. I'm not suggesting we patch $m->print ;)

Oh, I see what you mean. I think.

If, for absurd scenario, a component simply consisted of

>>>
<% $ARGS{output} %>
<<<

and $ARGS{output} purposefully contained additional newlines at start 
and end, you'd be screwed.

Unless of course you set

<%flags>
filter_newlines => 'none
</%flags>
# or even 'one' in the more likely situation that it's in a def or method block

And hell, it only takes wrapping the newlines with any character at 
all for it to resist destruction. Previous discussion have broken 
down on the premise that output would not be very predictable, 
figuring out which bits of the compiler to twiddle. The solution I've 
sketched out seems to be utterly predictable. And easily 
controllable. If that can be achieved in a Compiler-based solution, 
then that's great :)

So, leaving aside the issue of Compiler vs Request, what about the 
very concept of 'filter_newlines' (or better name) as a) Interp 
parameter and b) per-component flag? Would those still be good to go 
for a compiler-based version or does someone have a better way?




The other thing I forgot, is that something similar should probably 
happen to $m->content as well. (In this case, Dave's point about 
interpolated values does come home to roost, but again the flag of 
choice could be set on the component with content to prevent overly 
greedy stripping.)



By the way CJ, I haven't provided tests, because, well I wanted to 
run this up the flagpole first and see whether it a) met with 
approval and b) if so, what form it should take first.

Currently, I think it's falling down at a). *I* like it, but that's 
because it works for me and I haven't yet seen a working 
compiler-based version. But I'm not one of the core Mason dev team, 
but rather a designer who codes and who wants to not have to think 
about whether a given component needs a filter block to soak up 
surplus space ;)

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/