This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
To: Mason <mason-users@lists.sourceforge.net> From: Alex Robinson <alexr@cloudband.com> Subject: [Mason] Tags for Component Calls with Content Date: Fri, 13 Sep 2002 17:30:20 +0100 Firstly there's a very minor typo in the "Inline Perl Sections::Examples and Recommended Usage" part of the Developer's manual: <%perl xxx </%perl> >> ........... I'm not running 1.1 but I'm looking forward to 1.14 and so I've been trying to bring myself up to speed with the issues (and don't worry Dave - I don't plan to roll it straight out on to a live machine ;) My query is about component calls with content. For instance, I understand that under 1.1 you can do stuff like this: <&| /blah/comp1 &> <&| /blah/comp2 &> CONTENT <&| /blah/comp3 &> MORE CONTENT </&> <&| /blah/comp4 &> YET MORE CONTENT </&> </&> </&> That's great, but I have to say I dislike the look of all those anonymous </&> closing tags. 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 > Obviously, I could insert comments next to each individual closing tag instead, but I think the above would be much clearer and neater. Perhaps others would disagree. How difficult would it be to implement? I see this line in Lexer.pm's match_comp_content_call_end: >>>>> if ( $self->{current}{comp_source} =~ m,\G</&>,gc ) <<<<< which just needs to be changed to >>>>> if ( $self->{current}{comp_source} =~ m,\G</&[^>]*>,gc ) <<<<< but there I run out of steam in following Mason's internal logic. Presumably there's more to be changed? === To: Alex Robinson <alexr@cloudband.com> From: John Williams <williams@morinda.com> Subject: Re: [Mason] Tags for Component Calls with Content Date: Fri, 13 Sep 2002 11:51:22 -0600 (MDT) 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 === To: Alex Robinson <alexr@cloudband.com> From: Ian Robertson <ian@eziba.com> Subject: Re: [Mason] Tags for Component Calls with Content Date: Fri, 13 Sep 2002 14:16:29 -0400 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 === To: John Williams <williams@morinda.com> From: Ken Williams <ken@mathforum.org> Subject: Re: [Mason] Tags for Component Calls with Content Date: Sat, 14 Sep 2002 13:40:11 +1000 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 === To: Ken Williams <ken@mathforum.org> From: Dave Rolsky <autarch@urth.org> Subject: Re: [Mason] Tags for Component Calls with Content Date: Sat, 14 Sep 2002 02:03:29 -0500 (CDT) 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. === To: Mason <mason-users@lists.sourceforge.net> From: Alex Robinson <alexr@cloudband.com> Subject: Re: [Mason] Tags for Component Calls with Content Date: Sun, 15 Sep 2002 01:06:43 +0100 >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. === To: Alex Robinson <alexr@cloudband.com> From: David Wheeler <david@wheeler.net> Subject: Re: [Mason] Tags for Component Calls with Content Date: Sat, 14 Sep 2002 17:47:33 -0700 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 === To: David Wheeler <david@wheeler.net>, From: Alex Robinson <alexr@cloudband.com> Subject: Re: [Mason] Tags for Component Calls with Content Date: Sun, 15 Sep 2002 02:13:00 +0100 >> <&| 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. === To: Alex Robinson <alexr@cloudband.com> From: John Williams <williams@morinda.com> Subject: Re: [Mason] Tags for Component Calls with Content Date: Sun, 15 Sep 2002 09:21:53 -0600 (MDT) 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 === To: "Dave Rolsky" <autarch@urth.org>, "Ken Williams" <ken@mathforum.org> From: "Jonathan Swartz" <swartz@pobox.com> Subject: RE: [Mason] Tags for Component Calls with Content Date: Sun, 15 Sep 2002 09:29:31 -0700 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. === To: Jonathan Swartz <swartz@pobox.com> From: Dave Rolsky <autarch@urth.org> Subject: RE: [Mason] Tags for Component Calls with Content Date: Sun, 15 Sep 2002 11:37:12 -0500 (CDT) 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. === To: "Jonathan Swartz" <swartz@pobox.com>, From: Alex Robinson <alexr@cloudband.com> Subject: RE: [Mason] Tags for Component Calls with Content Date: Sun, 15 Sep 2002 17:41:59 +0100 >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? === To: Dave Rolsky <autarch@urth.org>, Mason <mason-users@lists.sourceforge.net> From: Alex Robinson <alexr@cloudband.com> Subject: RE: [Mason] Tags for Component Calls with Content Date: Sun, 15 Sep 2002 18:08:56 +0100 >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. === To: Alex Robinson <alexr@cloudband.com> From: Dave Rolsky <autarch@urth.org> Subject: RE: [Mason] Tags for Component Calls with Content Date: Sun, 15 Sep 2002 12:32:43 -0500 (CDT) 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. === To: "Dave Rolsky" <autarch@urth.org> From: "Jonathan Swartz" <swartz@pobox.com> Subject: RE: [Mason] Tags for Component Calls with Content Date: Sun, 15 Sep 2002 11:08:48 -0700 > 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... === To: "Jonathan Swartz" <swartz@pobox.com> From: Ken Williams <ken@mathforum.org> Subject: Re: [Mason] Tags for Component Calls with Content Date: Mon, 16 Sep 2002 10:53:23 +1000 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? === To: Jonathan Swartz <swartz@pobox.com> From: Dave Rolsky <autarch@urth.org> Subject: RE: [Mason] Tags for Component Calls with Content Date: Sun, 15 Sep 2002 20:46:53 -0500 (CDT) 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. === To: Dave Rolsky <autarch@urth.org> From: Ken Williams <ken@mathforum.org> Subject: Re: [Mason] Tags for Component Calls with Content Date: Mon, 16 Sep 2002 15:43:59 +1000 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. === To: Dave Rolsky <autarch@urth.org> From: Jonathan Swartz <swartz@pobox.com> Subject: RE: [Mason] Tags for Component Calls with Content Date: Mon, 16 Sep 2002 09:20:09 -0700 > 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! === To: Jonathan Swartz <swartz@pobox.com> From: John Williams <williams@morinda.com> Subject: RE: [Mason] Tags for Component Calls with Content Date: Thu, 19 Sep 2002 22:17:57 -0600 (MDT) 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 === To: John Williams <williams@morinda.com> From: Dave Rolsky <autarch@urth.org> Subject: RE: [Mason] Tags for Component Calls with Content Date: Fri, 20 Sep 2002 00:21:42 -0500 (CDT) 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 ;) === To: "John Williams" <williams@morinda.com> From: "Jonathan Swartz" <swartz@pobox.com> Subject: RE: [Mason] Tags for Component Calls with Content Date: Fri, 20 Sep 2002 07:22:06 -0700 > > 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. === To: John Williams <williams@morinda.com> From: Ken Williams <ken@mathforum.org> Subject: Re: [Mason] Tags for Component Calls with Content Date: Sat, 21 Sep 2002 14:08:30 +1000 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. === To: John Williams <williams@morinda.com> From: Ken Williams <ken@mathforum.org> Subject: Re: [Mason] Tags for Component Calls with Content Date: Sat, 21 Sep 2002 14:23:50 +1000 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. === To: Ken Williams <ken@mathforum.org> From: Dave Rolsky <autarch@urth.org> Subject: Re: [Mason] Tags for Component Calls with Content Date: Fri, 20 Sep 2002 23:32:11 -0500 (CDT) 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. === To: Dave Rolsky <autarch@urth.org> From: Ken Williams <ken@mathforum.org> Subject: Re: [Mason] Tags for Component Calls with Content Date: Sat, 21 Sep 2002 14:49:20 +1000 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. === To: "Ken Williams" <ken@mathforum.org>, "Dave Rolsky" <autarch@urth.org> From: "Jonathan Swartz" <swartz@pobox.com> Subject: RE: [Mason] Tags for Component Calls with Content Date: Sat, 21 Sep 2002 08:35:21 -0700 > >> 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. === To: Jonathan Swartz <swartz@pobox.com> From: John Williams <williams@morinda.com> Subject: RE: [Mason] Tags for Component Calls with Content Date: Sat, 21 Sep 2002 09:58:53 -0600 (MDT) 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. === To: Ken Williams <ken@mathforum.org> From: John Williams <williams@morinda.com> Subject: Re: [Mason] Tags for Component Calls with Content Date: Sun, 22 Sep 2002 23:40:07 -0600 (MDT) 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... === To: John Williams <williams@morinda.com>, Ken Williams <ken@mathforum.org> From: Jonathan Swartz <swartz@pobox.com> Subject: RE: [Mason] Tags for Component Calls with Content Date: Mon, 23 Sep 2002 10:57:17 -0700 > > > 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. === To: Jonathan Swartz <swartz@pobox.com> From: Ken Williams <ken@mathforum.org> Subject: Re: [Mason] Tags for Component Calls with Content Date: Tue, 24 Sep 2002 10:19:04 +1000 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 === To: Ken Williams <ken@mathforum.org> From: Jonathan Swartz <swartz@pobox.com> Subject: RE: [Mason] Tags for Component Calls with Content Date: Tue, 24 Sep 2002 09:26:11 -0700 > >>> <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? ===