Re: Leading/trailing newlines

heh.  sounds useful to me.  it would be nice to have > 1 field for the
<%flag> block :)

can you cobble together a couple of real world use cases, determine
the "correct" name for the flag, write up some docs, put together some
.t bits and submit a udiff to the list?

You'd probably see some traction then.

oh, and no flag set means status quo

On 9/23/07, Alex Robinson <[email protected]> wrote:
> >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 ;)
>


-- 
moo.

-------------------------------------------------------------------------
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/