Mason

On Fri, 13 Sep 2002, Alex Robinson wrote:

> Personally, I'd like to be able to do this:
>
> <&| /blah/comp1 &>
>   <&| /blah/comp2 &>
>     CONTENT
>     <&| /blah/comp3 &>
>       MORE CONTENT
>     </& comp3>
>     <&| /blah/comp4 &>
>       YET MORE CONTENT
>     </& comp4>
>   </& comp2>
> </& comp1 >

Actually, that is how I originally designed the ending tag, except that it
would validate that the tags matched, so you probably would have needed to
do </& /blah/comp1 &>.  </&> was also valid if you didn't want the
validation.  Dave doesn't like optional features, so he took it out.
Admittedly, I overdid the optional part, since I allowed </&| comp &>,
</&|&>, and maybe even </&|> forms as well.

But since this is the second request for this feature, I can no longer
resist the temptation to rub it in a little:

<BIG SMILEY> I TOLD YOU SO, DAVE </BIG SMILEY>

Ironically amused,

~ John Williams

We toyed with this for awhile.  Our approach was that the close tag
for a call to <& /foo/bar/comp:meth &> could be either </&> as before,
or </& comp:meth>.  In the later case, a match to everything following
the last / of the call had to match.  In the end, we decided against
it, but while we were toying, this is what we had:

package Eziba::Services::HtmlGenerationService::Lexer;

use strict;
use base qw( HTML::Mason::Lexer );

sub match_comp_content_call
{
    my $self = shift;

    if ( $self->{current}{comp_source} =~ /\G<&\|/gcs )
    {
	if ( $self->{current}{comp_source} =~ /\G(.*?)&>/gcs )
	{
	    my $call = $1;
            my( $comp_name ) = ( $call =~ m/\s*([^,]*)/ );
            $comp_name =~ s/\s+$//;
            $comp_name =~ s!.*/!!;
            push @{ $self->{current}{content_name_stack} ||= [] }, $comp_name;
	    $self->{current}{compiler}->component_content_call( call => $call );
	    $self->{current}{lines} += $call =~ tr/\n/\n/;

	    return 1;
	}
	else
	{
	    $self->throw_syntax_error("'<&|' without matching '&>'");
	}
    }
}

sub match_comp_content_call_end
{
    my $self = shift;

    if ( $self->{current}{comp_source} =~ m,\G</&,gc )
    {
        my $comp_name = pop  @{ $self->{current}{content_name_stack} };
        if ( $self->{current}{comp_source} =~
                 m/\G(?:\s*(${comp_name})\s*)?>/gc )
        {
            $self->{current}{compiler}->component_content_call_end;
            return 1;
        }
        else
        {
            # Don't confuse the compiler
            $self->{current}{compiler}->component_content_call_end;
	    $self->throw_syntax_error("'</&' has non-matching component name");
        }
    }
}

The "# Don't confuse the compiler" comment refers to the fact that if
we threw a syntax error without first closing the content call, that
error ended up getting overridden by the error that there weren't
enough close content tags.

   - Ian

>>>>> "AR" == Alex Robinson <alexr@...> writes:

 AR> I'm not running 1.1 but I'm looking forward to 1.14 and so I've
 AR> been trying to bring myself up to speed with the issues (and
 AR> don't worry Dave - I don't plan to roll it straight out on to a
 AR> live machine ;)

 AR> My query is about component calls with content. For instance, I
 AR> understand that under 1.1 you can do stuff like this:

 AR> <&| /blah/comp1 &>
 AR>   <&| /blah/comp2 &>
 AR>     CONTENT
 AR>     <&| /blah/comp3 &>
 AR>       MORE CONTENT
 AR>     </&>
 AR>     <&| /blah/comp4 &>
 AR>       YET MORE CONTENT
 AR>     </&>
 AR>   </&>
 AR> </&>


 AR> That's great, but I have to say I dislike the look of all those anonymous
 AR> </&> closing tags.

 AR> Personally, I'd like to be able to do this:

 AR> <&| /blah/comp1 &>
 AR>   <&| /blah/comp2 &>
 AR>     CONTENT
 AR>     <&| /blah/comp3 &>
 AR>       MORE CONTENT
 AR>     </& comp3>
 AR>     <&| /blah/comp4 &>
 AR>       YET MORE CONTENT
 AR>     </& comp4>
 AR>   </& comp2>
 AR> </& comp1 >

 AR> Obviously, I could insert comments next to each individual closing tag
 AR> instead, but I think the above would be much clearer and neater. Perhaps
 AR> others would disagree.

 AR> How difficult would it be to implement? I see this line in Lexer.pm's
 AR> match_comp_content_call_end:
 >>>>>> 
 AR>   if ( $self->{current}{comp_source} =~ m,\G</&>,gc )
 AR> <<<<<
 AR> which just needs to be changed to
 >>>>>> 
 AR>   if ( $self->{current}{comp_source} =~ m,\G</&[^>]*>,gc )
 AR> <<<<<

 AR> but there I run out of steam in following Mason's internal logic.
 AR> Presumably there's more to be changed?

On Saturday, September 14, 2002, at 03:51 AM, John Williams wrote:
> Actually, that is how I originally designed the ending tag, 
> except that it
> would validate that the tags matched, so you probably would 
> have needed to
> do </& /blah/comp1 &>.  </&> was also valid if you didn't want the
> validation.  Dave doesn't like optional features, so he took it out.
> Admittedly, I overdid the optional part, since I allowed </&| comp &>,
> </&|&>, and maybe even </&|> forms as well.
>
> But since this is the second request for this feature, I can no longer
> resist the temptation to rub it in a little:
>
> <BIG SMILEY> I TOLD YOU SO, DAVE </BIG SMILEY>

In fact, this incident happened twice - once between you and 
Dave, and once between me and Jon.  So now I can say 
I-told-Jon-so too. =)

A very different way to address this would be to introduce some 
kind of generic comment tag (I'm not actually proposing this 
specific syntax):

<&| /blah/comp1 &>
   <&| /blah/comp2 &>
     CONTENT
     <&| /blah/comp3 &>
       MORE CONTENT
     </&>  <# comp3 >
     <&| /blah/comp4 &>
       YET MORE CONTENT
     </&>  <# comp4 >
   </&>  <# comp2 >
</&>  <# comp1 >


  -Ken

On Sat, 14 Sep 2002, Ken Williams wrote:

> > <BIG SMILEY> I TOLD YOU SO, DAVE </BIG SMILEY>
>
> In fact, this incident happened twice - once between you and
> Dave, and once between me and Jon.  So now I can say
> I-told-Jon-so too. =)

Actually, if I recall correctly all I wanted was to enforce one style or
another.  I just didn't like the idea of this being ok:

  <&| foo &>
    <&| bar &>
      stuff
    </&>
  </& foo>

too weird for me.


-dave

/*==================
 http://www.urth.org
we await the New Sun
==================*/

>Actually, if I recall correctly all I wanted was to enforce one style or
>another.  I just didn't like the idea of this being ok:
>
>  <&| foo &>
>    <&| bar &>
>      stuff
>    </&>
>  </& foo>
>
>too weird for me.

or

  <&| foo &>
    <&| bar &>
      stuff
    </& foo>
  </& bar>


Well, if that's all, can we have it please? It's not as if you have to use
it ;)

What about it being a user configurable option?

 default - as is
 loose - allows anything after the ampersand
 strict - validating, requires exact matching
   [ which would "fix" apparent incorrect nestedness ]

Though I suppose that that would lead to potential incompatibilies in
components that people wanted to exchange.

Personally I'd go with just the loose style.

On Saturday, September 14, 2002, at 05:06  PM, Alex Robinson wrote:

>   <&| foo &>
>     <&| bar &>
>       stuff
>     </& foo>
>   </& bar>

Ooh, ick, your tags are out of order. How does that make sense? Did you 
mean this?

   <&| foo &>
     <&| bar &>
       stuff
     </& bar>
   </& foo>

David

-- 
David Wheeler                                     AIM: dwTheory
david@...                                 ICQ: 15726394
http://david.wheeler.net/                      Yahoo!: dew7e
                                                Jabber: Theory@...

>>   <&| foo &>
>>     <&| bar &>
>>       stuff
>>     </& foo>
>>   </& bar>
>
>Ooh, ick, your tags are out of order. How does that make sense? Did you
>mean this?

That's exactly what I meant to say (just not explicitly enough, obviously).
ie. that a loose, non-validated, anything-goes-way would allow you to write
code that looks as if it is incorrectly nested. The above code would run
exactly the same as if the closing tags were in the correct order or if the
commenty bits were missing. This seems to be the advantage of validating
that the exact same name is used again and so "well-formedness" could be
enforced.

However, what if you were to use a variable for the component call path?

In fact, what happens to the scope of vars in calls with content

% $foo = $bar;
<&| $foo &>
  STUFF
% $foo = $nubar;
</& $foo>
<% $foo %>


Oh dear. I have really confused myself.

Of course, if I had a version of 1.14 [0] complete with
loose-commenty-style end tags, I'd be able to work this out for myself :)


[0] I know it doesn't exist yet - I'm just lobbying.

On Sun, 15 Sep 2002, Alex Robinson wrote:
> However, what if you were to use a variable for the component call path?
>
> In fact, what happens to the scope of vars in calls with content
>
> % $foo = $bar;
> <&| $foo &>
>   STUFF
> % $foo = $nubar;
> </& $foo>
> <% $foo %>

My original implementation expected the ending tag to match the literal
contents of the <&| tag, up to the first comma, so the example above would
work, because it's looking at the string '$foo', not the value of "$foo".
Of course this can easily be fooled by more complex things, like
<&| &comp_based_on($this, $that, $theother), etc => 1 &>
which is why the alternate </&> form is always needed.

(Mason punts to perl if the comp is not a bareword (or barepath), and lets
perl evaluate the complex casees.)

~ John Williams

We had this same conversation a while ago, here was the reasoning for just
using </&>:

1. Some forms of <&, like, <&| ($d ? '/foo' : '/bar') &>, would be
impossible to close gracefully in a name-based fashion.

2. We didn't want to allow two kinds of syntaxes as Dave says below.

3. Mason programmers have to deal with multiple closing braces all the time
anyway, i.e.

% for
%   if
%   }
% }

so there's no point in solving this "problem" just for <&.

A comment marker after </&> would suffice. I'd vote for finally implementing
<%-- --%>, which is standard in several of our brethren markup languages.

Jon

> -----Original Message-----
> From: mason-users-admin@...
> [mailto:mason-users-admin@... Behalf Of Dave Rolsky
> Sent: Saturday, September 14, 2002 12:03 AM
> To: Ken Williams
> Cc: John Williams; Alex Robinson; Mason
> Subject: Re: [Mason] Tags for Component Calls with Content
>
>
> On Sat, 14 Sep 2002, Ken Williams wrote:
>
> > > <BIG SMILEY> I TOLD YOU SO, DAVE </BIG SMILEY>
> >
> > In fact, this incident happened twice - once between you and
> > Dave, and once between me and Jon.  So now I can say
> > I-told-Jon-so too. =)
>
> Actually, if I recall correctly all I wanted was to enforce one style or
> another.  I just didn't like the idea of this being ok:
>
>   <&| foo &>
>     <&| bar &>
>       stuff
>     </&>
>   </& foo>
>
> too weird for me.
>
>
> -dave
>
> /*==================
> http://www.urth.org
> we await the New Sun
> ==================*/
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Mason-users mailing list
> Mason-users@...
> https://lists.sourceforge.net/lists/listinfo/mason-users
>

On Sun, 15 Sep 2002, Jonathan Swartz wrote:

> A comment marker after </&> would suffice. I'd vote for finally implementing
> <%-- --%>, which is standard in several of our brethren markup languages.

I'd be fine with including a comment marker in 1.14, although I don't
think <%-- --%> is the right choice.  First of all, it conflicts with the
substitution tag.  Second, Mason syntax current has two non-block tags,
'<% %>' and '<& &>', each of which use a single non-word character to
denote their meaning.  Adding in '<%-- --%>' breaks that pattern.

I'd suggest we simply use '<# #>', as that fits in better with the current
syntax.

If people don't like this, check out John Williams' code contribution
HTML::Mason::Lexer::MSP on the MHQ site, which provides JSP/ASP style
syntax for Mason, including a '<%-- --%>' tag for comments.

John, how about sticking that on CPAN, BTW?  People in the past have
requested such a syntax for Mason, and since I don't think the syntax
currently used by the Mason core will change any time real soon, this
would be a good alternative.


-dave

/*==================
 http://www.urth.org
we await the New Sun
==================*/

>so there's no point in solving this "problem" just for <&.
>
>A comment marker after </&> would suffice. I'd vote for finally implementing
><%-- --%>, which is standard in several of our brethren markup languages.
>
>Jon

OK. Fair enough. Consider my feature request withdrawn.

I'd still like to know the answer as to what happens to

<&| comp1 &>
%  $foo = 'bar';
   <&| comp2 &>
%  $foo = 'nubar';
     <&| comp3 &>
%  $foo = 'something else';
     </&>
  </&>
</&>
<% $foo %>

I know this is a highly unlikely construct, but does $foo come out the
other side as 'bar'?

And presumably, because of the order the comps are actually called (comp3,
comp2, comp1), there's no way to have the outer component pass anything to
the innermost one?

>I'd suggest we simply use '<# #>', as that fits in better with the current
>syntax.

That would be a nice addition to my personal favourite commenting method - %#

>If people don't like this, check out John Williams' code contribution
>HTML::Mason::Lexer::MSP on the MHQ site, which provides JSP/ASP style
>syntax for Mason, including a '<%-- --%>' tag for comments.
>
>John, how about sticking that on CPAN, BTW?  People in the past have
>requested such a syntax for Mason, and since I don't think the syntax
>currently used by the Mason core will change any time real soon, this
>would be a good alternative.

And where does this leave sharing components with other people? Fair enough
that some people might want to go it alone, but shouldn't it be made clear
to people that it really isn't advised?

I respectfully suggest that the correct solution is to discuss whether such
a syntax change is actually necessary. And if it is, to pencil it firmly in
to the schedule. For around the same time that Perl 6 comes out.

On Sun, 15 Sep 2002, Alex Robinson wrote:

> And where does this leave sharing components with other people? Fair enough
> that some people might want to go it alone, but shouldn't it be made clear
> to people that it really isn't advised?

It leaves them unable to share with others ;)

Same with those who've asked for an XML-based syntax in the past.

> I respectfully suggest that the correct solution is to discuss whether such
> a syntax change is actually necessary. And if it is, to pencil it firmly in
> to the schedule. For around the same time that Perl 6 comes out.

We have discussed changing the syntax at some point in the future.  I'm of
mixed feelings about it myself.  But it sure won't happen any time soon,
if it ever happens at all.

So for those who really like Mason except they _really_ hate the syntax,
it is now possible to plug your own syntax into Mason, relatively easily.


-dave

/*==================
 http://www.urth.org
we await the New Sun
==================*/

> I'd be fine with including a comment marker in 1.14, although I don't
> think <%-- --%> is the right choice.  First of all, it conflicts with the
> substitution tag.

The conflict is pretty minor - with something like <%--$x%>, and then this
is easily solved with a space after %, which is pretty standard style. One
can't use <%init()%> or <%args()%> without a space either.

> Second, Mason syntax current has two non-block tags,
> '<% %>' and '<& &>', each of which use a single non-word character to
> denote their meaning.  Adding in '<%-- --%>' breaks that pattern.
>
> I'd suggest we simply use '<# #>', as that fits in better with the current
> syntax.

This is a pattern I actually don't want to continue...Every new <c c> tag
increases the chances of accidental tag inclusion in a document, makes it
less likely that editors will do the right thing, and clutters the syntax
with random characters.

I'm not fighting hard for <%-- --%> if folks don't like it -- a new comment
marker isn't the most essential need facing us. Even <%#comment %> would
work for a middle-of-the-line comment, I guess. I just don't want to go
further down the <c c> road.

>
> If people don't like this, check out John Williams' code contribution
> HTML::Mason::Lexer::MSP on the MHQ site, which provides JSP/ASP style
> syntax for Mason, including a '<%-- --%>' tag for comments.
>
> John, how about sticking that on CPAN, BTW?  People in the past have
> requested such a syntax for Mason, and since I don't think the syntax
> currently used by the Mason core will change any time real soon, this
> would be a good alternative.

I agree that CPAN is the best place for modules. But we should start
thinking soon about having a different namespace for contributed modules, to
keep clear the distinction between core Mason versus contributed Mason.

DBI has DBIx for this purpose. Someone at the last SF user's group suggested
Masonx at the CPAN top level for contributed Mason modules. It doesn't have
quite the same ring, but...

Jon

On Monday, September 16, 2002, at 04:08 AM, Jonathan Swartz wrote:

>> I'd be fine with including a comment marker in 1.14, although I don't
>> think <%-- --%> is the right choice.  First of all, it 
>> conflicts with the
>> substitution tag.
>
> The conflict is pretty minor - with something like <%--$x%>, 
> and then this
> is easily solved with a space after %, which is pretty standard 
> style. One
> can't use <%init()%> or <%args()%> without a space either.

I'd chalk all of those up to bugs in the parser.  Really, each 
of those is unambiguously a substitution tag, and only 
superficially resembles something else.


> I agree that CPAN is the best place for modules. But we should start
> thinking soon about having a different namespace for 
> contributed modules, to
> keep clear the distinction between core Mason versus contributed Mason.
>
> DBI has DBIx for this purpose. Someone at the last SF user's 
> group suggested
> Masonx at the CPAN top level for contributed Mason modules. It 
> doesn't have
> quite the same ring, but...
>

I'm not such a fan of the DBIx namespace, actually.  How about 
something like Mason::Contrib or HTML::Mason::Contrib?

  -Ken

On Sun, 15 Sep 2002, Jonathan Swartz wrote:

> The conflict is pretty minor - with something like <%--$x%>, and then this
> is easily solved with a space after %, which is pretty standard style. One
> can't use <%init()%> or <%args()%> without a space either.

Actually, <%init()%> works just fine, thank you ;)

> This is a pattern I actually don't want to continue...Every new <c c> tag
> increases the chances of accidental tag inclusion in a document, makes it
> less likely that editors will do the right thing, and clutters the syntax
> with random characters.
>
> I'm not fighting hard for <%-- --%> if folks don't like it -- a new comment
> marker isn't the most essential need facing us. Even <%#comment %> would
> work for a middle-of-the-line comment, I guess. I just don't want to go
> further down the <c c> road.

If that's the case, then I don't think we should introduce a comment tag
at all.

If we're going to change the syntax, let's change it all at once (some
time in the future).

> I agree that CPAN is the best place for modules. But we should start
> thinking soon about having a different namespace for contributed modules, to
> keep clear the distinction between core Mason versus contributed Mason.
>
> DBI has DBIx for this purpose. Someone at the last SF user's group suggested
> Masonx at the CPAN top level for contributed Mason modules. It doesn't have
> quite the same ring, but...

In response to Ken's suggested, Mason::Contrib, I don't like that all that
much because it adds two levels where Mason has one.

I kind of like MasonX (with a capital 'x') myself.  Or HTML::MasonX.  But
given that we plan to change the namespace to just Mason:: in the next
major release (1.20), I think it might be best to simply encourage people
to use MasonX now.


-dave

/*==================
 http://www.urth.org
we await the New Sun
==================*/

On Monday, September 16, 2002, at 11:46 AM, Dave Rolsky wrote:
> But given that we plan to change the namespace to just Mason:: 
> in the next
> major release (1.20),

Um, really?  I hope not.

  -Ken

> In response to Ken's suggested, Mason::Contrib, I don't like that all that
> much because it adds two levels where Mason has one.

I agree, and this will become more cumbersome as the number of modules
increases. We need a short name.

>
> I kind of like MasonX (with a capital 'x') myself.  Or HTML::MasonX.  But
> given that we plan to change the namespace to just Mason:: in the next
> major release (1.20), I think it might be best to simply encourage people
> to use MasonX now.

I like MasonX!

Jon

Dave Rolsky writes:

 > I kind of like MasonX (with a capital 'x') myself.  Or HTML::MasonX.  But
 > given that we plan to change the namespace to just Mason:: in the next
 > major release (1.20), I think it might be best to simply encourage people
 > to use MasonX now.
 > 

Wow. I follow the mason-devel list casually, but I missed the
discussion of this change. 

With apologies if this has already been hashed out, could I ask why
changing the top-level namespace is necessary?

I know that Mason is useful in non-HTML contexts, and that the HTML
namespace membership therefore isn't completely accurate. But changing
module names is a really big deal -- an even bigger deal (unless
complete backwards compatibility with no performance hit is possible)
than changing parts of the public API.

At AllAfrica, we use Mason in a production environment, across many
servers and with thousands of active components. We depend on Mason
utterly and completely, and are huge fans of both the platform and of
the development process that continues to refine and improve that
platform. But I'd like to make a plea here to carefully consider the
needs of large-scale users as you try to find that elusive balance
between innovation and stability.

In particular, changing the top-level namespace doesn't seem like
innovation. In my view, namespaces are -- at best -- indications of a
module's purview or characteristics. So I don't see "HTML::Mason" as
limiting, just as a cue that most folks who use Mason do so in the
context of back-end web programming. 

Kwin

Hi Kwindla,

I'm not especially thrilled about it either.  It would have made more 
sense to do this in conjunction with a big huge API change, but as far 
as I know no such huge change is planned for 2.0.  I'm not really in 
favor of changing to Mason:: myself, but I haven't been very vocal about 
it.

  -Ken


On Tuesday, September 17, 2002, at 02:31  AM, Kwindla Hultman Kramer 
wrote:

>
> Dave Rolsky writes:
>
>> I kind of like MasonX (with a capital 'x') myself.  Or HTML::MasonX.  
>> But
>> given that we plan to change the namespace to just Mason:: in the next
>> major release (1.20), I think it might be best to simply encourage 
>> people
>> to use MasonX now.
>>
>
> Wow. I follow the mason-devel list casually, but I missed the
> discussion of this change.
>
> With apologies if this has already been hashed out, could I ask why
> changing the top-level namespace is necessary?
>
> I know that Mason is useful in non-HTML contexts, and that the HTML
> namespace membership therefore isn't completely accurate. But changing
> module names is a really big deal -- an even bigger deal (unless
> complete backwards compatibility with no performance hit is possible)
> than changing parts of the public API.
>
> At AllAfrica, we use Mason in a production environment, across many
> servers and with thousands of active components. We depend on Mason
> utterly and completely, and are huge fans of both the platform and of
> the development process that continues to refine and improve that
> platform. But I'd like to make a plea here to carefully consider the
> needs of large-scale users as you try to find that elusive balance
> between innovation and stability.
>
> In particular, changing the top-level namespace doesn't seem like
> innovation. In my view, namespaces are -- at best -- indications of a
> module's purview or characteristics. So I don't see "HTML::Mason" as
> limiting, just as a cue that most folks who use Mason do so in the
> context of back-end web programming.
>
> Kwin

On Wed, 18 Sep 2002, Ken Williams wrote:

> I'm not especially thrilled about it either.  It would have made more
> sense to do this in conjunction with a big huge API change, but as far
> as I know no such huge change is planned for 2.0.  I'm not really in
> favor of changing to Mason:: myself, but I haven't been very vocal about
> it.

Actually, I thought we agreed (on the dev list) to push this off to 2.0.
Since we have no idea what will be in 2.0, I suspect this will be in the
fairly distant future (2-3 years, at least).


-dave

/*==================
 http://www.urth.org
we await the New Sun
==================*/

>Actually, I thought we agreed (on the dev list) to push this off to 2.0.
>Since we have no idea what will be in 2.0, I suspect this will be in the
>fairly distant future (2-3 years, at least).

Phew.

That would also be the time to make any changes to the syntax (if any). And
move over to Perl 6 and rewrite everything using Quantum::Superpositions.

Anyhow, this being a content free post...

Is it possible to have 2 installations of Mason (1.05 & 1.1*) on the same
machine and to toggle between which one you want to use? Or would one have
to reinstall the version you wanted to use each time you wanted to switch?

> > I'm not especially thrilled about it either.  It would have made more
> > sense to do this in conjunction with a big huge API change, but as far
> > as I know no such huge change is planned for 2.0.  I'm not really in
> > favor of changing to Mason:: myself, but I haven't been very vocal about
> > it.
>
> Actually, I thought we agreed (on the dev list) to push this off to 2.0.
> Since we have no idea what will be in 2.0, I suspect this will be in the
> fairly distant future (2-3 years, at least).

I've moved the task to 2.0 and added a note that it will require community
debate before proceeding.

On Wed, 18 Sep 2002, Alex Robinson wrote:

> Is it possible to have 2 installations of Mason (1.05 & 1.1*) on the same
> machine and to toggle between which one you want to use? Or would one have
> to reinstall the version you wanted to use each time you wanted to switch?

You could install one in a non-standard directory (say
/usr/local/lib/new-mason) and then when you wanted to use the new mason
you'd add this:

  use lib '/usr/local/lib/new-mason';

to your code _before_ loading HTML::Mason or any other Mason modules.


-dave

/*==================
 http://www.urth.org
we await the New Sun
==================*/

>You could install one in a non-standard directory (say
>/usr/local/lib/new-mason) and then when you wanted to use the new mason
>you'd add this:

I've cocked it up. I watched aghast as 1.13 installed over the top of my
1.05. I thought perl Makefile.PL PREFIX=/<path> would do the trick but
obviously not. What should I actually have done?

That aside, 1.13 works fine and it took no time at all to tweak my old
handler. Props to the Mason team once again.

On Fri, 20 Sep 2002, Alex Robinson wrote:

> >You could install one in a non-standard directory (say
> >/usr/local/lib/new-mason) and then when you wanted to use the new mason
> >you'd add this:
>
> I've cocked it up. I watched aghast as 1.13 installed over the top of my
> 1.05. I thought perl Makefile.PL PREFIX=/<path> would do the trick but
> obviously not. What should I actually have done?

I usually do 'perl Makefile.PL LIB=...'.  But I thought PREFIX should work
as well, but what do I know.  EU::MakeMaker is a scary thing, though the
new versions are better.


-dave

/*==================
 http://www.urth.org
we await the New Sun
==================*/

On Mon, 16 Sep 2002, Jonathan Swartz wrote:

> I like MasonX!

So, if I put the MSP lexer on CPAN, should I call it MasonX::Lexer::MSP?


A few comments on the discussion:

Have we rejected both </& comp> and <%-- comment --%>?  That leaves the
users with no good way to mark their </&> tags when they are nested or far
from the start tag.

My preference would be to implement </& comp>, but only if it
tries to validate that it matches up with the start tag.  The <%# comment
tag %> option is a bit fragile, since having a line feed in it results in
a syntax error, as someone has pointed out before.

If we change the namespace to Mason::whatever, is it possible to also
install stubs in HTML::Mason::whatever which would do nothing except
inherit from the real modules?  This would provide backward-compatibility.

If we *ever* change the Mason syntax, it would probably be wise to do it
at the same time we change the namespace.

One more wild idea (inspired by perl6):  would it be possible to support
two different syntaxes, and be able to select them via an interp parameter
(to set the site default) OR via a setting in the <%flags> section (so
3rd-party modules can be sure they are being parse correctly)?  If the
syntax for the <%flags> tag was different, we would have to check for both
versions before starting the parse.

~ John Williams

On Thu, 19 Sep 2002, John Williams wrote:

> So, if I put the MSP lexer on CPAN, should I call it MasonX::Lexer::MSP?

Um, I think so.  Or HTML::MasonX?  But that sounds dumb.

> A few comments on the discussion:
>
> Have we rejected both </& comp> and <%-- comment --%>?  That leaves the
> users with no good way to mark their </&> tags when they are nested or far
> from the start tag.
>
> My preference would be to implement </& comp>, but only if it
> tries to validate that it matches up with the start tag.  The <%# comment
> tag %> option is a bit fragile, since having a line feed in it results in
> a syntax error, as someone has pointed out before.

But there's too many problems with </& comp>, as the discussion way back
when on the dev list brought up.  There's no _intuitive_ way to do it.  Do
you match the comp, the part before the comma, the whole thing?

I'm not sure why you think <%# %> would have problems with newlines.  We'd
parse it different from a substitution tag if it was implemented.  I still
like <# #>, just for consistency, but Jon won't go for it.

> If we change the namespace to Mason::whatever, is it possible to also
> install stubs in HTML::Mason::whatever which would do nothing except
> inherit from the real modules?  This would provide backward-compatibility.

Yep, we could do something like this:

  *HTML::Mason::Interp = *Mason::Interp;
  *HTML::Mason::ApacheHandler = *Mason::ApacheHandler;

etc.

> If we *ever* change the Mason syntax, it would probably be wise to do it
> at the same time we change the namespace.

I was also thinking of other possible 2.0-worthy changes, like supporting
only mod_perl 2.0 or something like that that we might consider in the
future.

> One more wild idea (inspired by perl6):  would it be possible to support
> two different syntaxes, and be able to select them via an interp parameter
> (to set the site default) OR via a setting in the <%flags> section (so
> 3rd-party modules can be sure they are being parse correctly)?  If the
> syntax for the <%flags> tag was different, we would have to check for both
> versions before starting the parse.

Having multiple lexer's right now is pretty simple, you'd just need
multiple interpreter's.  Having it set via a flag is obviously trickier,
but not that hard.

I don't think encouraging people to use two different syntaxes (or more)
on one application/site is a good idea though ;)


-dave

/*==================
 http://www.urth.org
we await the New Sun
==================*/

> > I like MasonX!
>
> So, if I put the MSP lexer on CPAN, should I call it MasonX::Lexer::MSP?

Yup. No HTML::, to answer Dave's question.

>
> Have we rejected both </& comp> and <%-- comment --%>?  That leaves the
> users with no good way to mark their </&> tags when they are nested or far
> from the start tag.
>
> My preference would be to implement </& comp>, but only if it
> tries to validate that it matches up with the start tag.  The <%# comment
> tag %> option is a bit fragile, since having a line feed in it results in
> a syntax error, as someone has pointed out before.

I forgot, too, that <%# %> wouldn't work right now and that we'd need to
parse it separately.

But I still think your point is valid: <%# %> poses a readability issue with
a comment spanning many lines, because the ending is identical to that of <%
%>. <%# comment #%> would solve this, but it may look harsh for short
one-line comments.

Jon

On Thursday, September 19, 2002, at 01:10  AM, Alex Robinson wrote:
> Anyhow, this being a content free post...
>
> Is it possible to have 2 installations of Mason (1.05 & 1.1*) 
> on the same
> machine and to toggle between which one you want to use? Or 
> would one have
> to reinstall the version you wanted to use each time you wanted 
> to switch?

Hi Alex,

This sort of thing doesn't have good support in Perl.  The only 
good way is to install the two versions in two different 
locations (using LIB= or PREFIX= when installing) and then 
change @INC (using 'use lib' or $ENV{PERL5LIB} or 'perl -I') in 
the two different processes.

It's probably *not* possible to use two different versions of 
Mason in the same process, i.e. to have $ah1 a 1.05 
ApacheHandler and $ah2 a 1.10 ApacheHandler, without some 
serious mocky-mock.

  -Ken

On Friday, September 20, 2002, at 02:17  PM, John Williams wrote:
> My preference would be to implement </& comp>, but only if it
> tries to validate that it matches up with the start tag.  
> The <%# comment
> tag %> option is a bit fragile, since having a line feed in it 
> results in
> a syntax error, as someone has pointed out before.

Thing is, the following is perfectly valid syntax in the current 
version of Mason.

     <%# This comment explains what's happening below
       $foo->really_long_something_or_over %>

So this has potential for breakage if we implement it.

  -Ken

On Friday, September 20, 2002, at 02:17  PM, John Williams wrote:

> On Mon, 16 Sep 2002, Jonathan Swartz wrote:
>
>> I like MasonX!
>
> So, if I put the MSP lexer on CPAN, should I call it 
> MasonX::Lexer::MSP?

<whimper>Really, does this MasonX namespace seem like a good 
idea?</whimper>

> If we change the namespace to Mason::whatever, is it possible to also
> install stubs in HTML::Mason::whatever which would do nothing except
> inherit from the real modules?  This would provide 
> backward-compatibility.

But that would prevent you from having HTML::Mason and Mason 
installed at the same time, which could be a very necessary 
migration strategy.

> If we *ever* change the Mason syntax, it would probably be wise 
> to do it
> at the same time we change the namespace.

Agreed.  If we ever do that either.

  -Ken

On Sat, 21 Sep 2002, Ken Williams wrote:

> Thing is, the following is perfectly valid syntax in the current
> version of Mason.
>
>      <%# This comment explains what's happening below
>        $foo->really_long_something_or_over %>
>
> So this has potential for breakage if we implement it.

That is very much not supported.  The fact that it works is entirely
coincidental, not intentional.  Anybody who's been using that has been
doing so because they discovered it by accident, and there's never been
any reason to assume it'd continue to work in the future.


-dave

/*==================
 http://www.urth.org
we await the New Sun
==================*/

On Saturday, September 21, 2002, at 02:32  PM, Dave Rolsky wrote:

> On Sat, 21 Sep 2002, Ken Williams wrote:
>
>> Thing is, the following is perfectly valid syntax in the current
>> version of Mason.
>>
>>      <%# This comment explains what's happening below
>>        $foo->really_long_something_or_over %>
>>
>> So this has potential for breakage if we implement it.
>
> That is very much not supported.  The fact that it works is entirely
> coincidental, not intentional.  Anybody who's been using that has been
> doing so because they discovered it by accident, and there's never been
> any reason to assume it'd continue to work in the future.
>

I disagree strongly.  The <% %> tag is documented to allow a 
perl expression inside it.  Perl expressions can contain 
comments.  One of the most powerful features of Mason is that it 
steps out of the way when Perl should take over.

So the following is also allowed:

  <% ($one,   # The first thing
      $two,   # The second thing
      $three, # The third thing
     )[$x] %>

It can be very useful to have comments in Perl code!

I don't like the idea of changing the tag to contain "generic 
perl code, as long as you don't want to use certain stuff in 
there that we've decided you can't use."  One reason is backward 
compatibility.  Another is that it breaks a certain kind of 
purity in the language.

Unfortunately, there's really no room in Mason's syntax to 
expand without breaking backward compatibility.  The only really 
valid things to add to a language without breakage are those 
things that currently produce syntax errors.  So I'm just 
advocating a little care here.

  -Ken

> >> Thing is, the following is perfectly valid syntax in the current
> >> version of Mason.
> >>
> >>      <%# This comment explains what's happening below
> >>        $foo->really_long_something_or_over %>
> >>
> >> So this has potential for breakage if we implement it.
> >
> > That is very much not supported.  The fact that it works is entirely
> > coincidental, not intentional.  Anybody who's been using that has been
> > doing so because they discovered it by accident, and there's never been
> > any reason to assume it'd continue to work in the future.
> >
>
> I disagree strongly.  The <% %> tag is documented to allow a
> perl expression inside it.  Perl expressions can contain
> comments.  One of the most powerful features of Mason is that it
> steps out of the way when Perl should take over.

Yes. The "it isn't supported if it isn't documented explicitly" argument
only works if you have a very comprehensive language specification that
spells everything out to the letter. We have nothing of the sort, so to a
certain extent users must figure out what works by a combination of common
sense and trial & error. It is not unreasonable for a user to expect the
above comment structure to work.

If we break either <%# or <%--$x + $y--%>, then we have to treat them as
backward incompatibilities. The question then becomes how many users are
likely to be affected. I'd expect <%-- --%> to be less problematic in this
regard, especially if the parser is sophisticated enough to still be able to
treat <%--$x%> as an expression.

Jon

On Sat, 21 Sep 2002, Jonathan Swartz wrote:
> > >> Thing is, the following is perfectly valid syntax in the current
> > >> version of Mason.
> > >>
> > >>      <%# This comment explains what's happening below
> > >>        $foo->really_long_something_or_over %>
> > >>
> > >> So this has potential for breakage if we implement it.

Personally, I think that construct is so ugly, I _want_ it to break. :)

And the fact that <%# comment %> is a syntax error give it support from
Ken's own arguments.

> > I disagree strongly.  The <% %> tag is documented to allow a
> > perl expression inside it.  Perl expressions can contain
> > comments.  One of the most powerful features of Mason is that it
> > steps out of the way when Perl should take over.

They could still put comments in, as long as the comment is not first
character.

> If we break either <%# or <%--$x + $y--%>, then we have to treat them as
> backward incompatibilities. The question then becomes how many users are
> likely to be affected. I'd expect <%-- --%> to be less problematic in this
> regard, especially if the parser is sophisticated enough to still be able to
> treat <%--$x%> as an expression.

One of points JSP makes is that <%-- --%> can contain _anything_ except
the string "--%>", and they recommend escaping one of those characters to
get around that: "--\%>".  Since I can easily imagine this being used to
comment out sections containing other mason tags, I agree with them.

Perl being what it is, I don't think we can reuse the <% %> tags without
introducing some sort of incompatibility, but I agree with Jon that using
other tags would be a worse idea.

~ John Williams

On Sat, 21 Sep 2002, Ken Williams wrote:
> On Friday, September 20, 2002, at 02:17  PM, John Williams wrote:
> > On Mon, 16 Sep 2002, Jonathan Swartz wrote:
> >
> >> I like MasonX!
> >
> > So, if I put the MSP lexer on CPAN, should I call it
> > MasonX::Lexer::MSP?
>
> <whimper>Really, does this MasonX namespace seem like a good
> idea?</whimper>

I'll call it anything people can agree on.  I'm not picky about the name
at all.

> > If we change the namespace to Mason::whatever, is it possible to also
> > install stubs in HTML::Mason::whatever which would do nothing except
> > inherit from the real modules?  This would provide
> > backward-compatibility.
>
> But that would prevent you from having HTML::Mason and Mason
> installed at the same time, which could be a very necessary
> migration strategy.

But no worse than the current situation.  They need to figure out how to
use a different lib path.  Maybe we should add that to the docs...

~ John Williams

> > > So, if I put the MSP lexer on CPAN, should I call it
> > > MasonX::Lexer::MSP?
> >
> > <whimper>Really, does this MasonX namespace seem like a good
> > idea?</whimper>
>
> I'll call it anything people can agree on.  I'm not picky about the name
> at all.

MasonX is (1) wonderfully short and (2) easily distinguishable from the core
namespace (HTML::Mason). I'm pretty sold on it, unless Ken has an
alternative that satisfies these two properties.

Jon

On Tuesday, September 24, 2002, at 03:57  AM, Jonathan Swartz wrote:

>>>> So, if I put the MSP lexer on CPAN, should I call it
>>>> MasonX::Lexer::MSP?
>>>
>>> <whimper>Really, does this MasonX namespace seem like a good
>>> idea?</whimper>
>>
>> I'll call it anything people can agree on.  I'm not picky 
>> about the name
>> at all.
>
> MasonX is (1) wonderfully short and (2) easily distinguishable 
> from the core
> namespace (HTML::Mason).

However, it doesn't say what it means.  It's too cryptic.  I 
personally find it ugly, though I guess you don't agree.  And 
it's yet another top level CPAN namespace, which the world needs 
like a hole in the head.


> I'm pretty sold on it, unless Ken has an
> alternative that satisfies these two properties.

I do still like Mason::Contrib.  It says what it means, and it's 
a top-level namespace that we may use in the future anyway.

  -Ken

> >>> <whimper>Really, does this MasonX namespace seem like a good
> >>> idea?</whimper>
> >>
> >> I'll call it anything people can agree on.  I'm not picky
> >> about the name
> >> at all.
> >
> > MasonX is (1) wonderfully short and (2) easily distinguishable
> > from the core
> > namespace (HTML::Mason).
>
> However, it doesn't say what it means.  It's too cryptic.  I
> personally find it ugly, though I guess you don't agree.  And
> it's yet another top level CPAN namespace, which the world needs
> like a hole in the head.

The name "Mason" doesn't say what it means either. You have to read about it
to find out.

Not needing another top level CPAN namespace is perhaps the most compelling
reason. My only response is that, glancing over the current top level CPAN
namespace, I think the damage is already done. I'm not sure we could
possibly hurt it.

>
> I do still like Mason::Contrib.  It says what it means, and it's
> a top-level namespace that we may use in the future anyway.

I'll be annoyed at you every time I have to type "::Contrib". :) Seriously,
I find that much uglier than MasonX, which I predict we'll get used to in no
time. Shorthand has a way of becoming familiar very quickly for programmers.

I'm not sure we'll ever change our namespace. So we might very well only end
up using one top-level name.

Other voices?

Jon