Re: Patch and test to allow component calls

Here was the last conversation on this topic:

http://marc.theaimsgroup.com/?t=103193527500003&r=1&w=2

Summary: We all agree that it would be nice to conveniently match a </&> 
with its starting tag, but differ on the method.

Solutions include:

1. Forcing the closing tag to contain the exact path, e.g. </& 
/foo/bar>. This doesn't work because the starting tag may be an 
arbitrarily complex expression, e.g. <& $foo ? '/comp1' : $bar ? ... &>

2. Allowing the closing tag to either be empty or to match the exact 
path, or a subset of the exact path. Dave R felt the parsing would be 
too complicated, and also didn't like having two closing tag syntaxes.

3. Allowing the closing tag to either be empty or to have arbitrary 
text, as suggested in Alex's email. This isn't as bad from a parsing 
standpoint. But I have always been against this option and now that I 
consider it again, am even MORE DEAD SET against it. One should not be 
able to put arbitrary text inside a language's syntactical tag! It is 
completely inconsistent with the rest of the language, and it will 
suggest incorrectly to the casual reader that there is some sort of 
matching enforcement with the starting tag.

4. Allow #3 but only via a configurable interp or compiler option. I'm 
rejecting this too because it is already hard enough to share components 
and adapt other people's sites without splintering the syntax further.

5. Create a convenient comment marker that you can place just after the 
</&>. (%# won't work because it has to be on a separate line.) This is 
my preferred solution, because it avoids violating a syntactic tag, and 
it creates a useful new syntax that could be used beyond </&> - we have 
often talked about needing a comment marker anyway. On the above thread 
we considered the following comment options:

* <%-- comment --%> - suggested by me, from other systems such as JSP, 
but some people including Dave R find it too html-ish

* <# comment #> - suggested by Dave R, I don't like this because I don't 
want to move any further in the direction of a million <C C> tags, where 
C is a random character

* <%# comment %> - this already works with a single line. With multiple 
lines, each line has to be blank or begin with #, e.g.

    <%
      # comment
      # further comment
     %>

I like this because it is succint, and doesn't require any changes to 
the parser, other than perhaps getting rid of the extra newline 
generated by the multiline form. Did other people have problems with 
this? Here's how it would look with cwc:

<& /foo |&>
   <& /bar |&>
   ...
   </&> <%# /bar %>
</&> <%# /foo %>


Jon

Alex Robinson wrote:

> Given the imminentish release of 1.3 and the inclusion of Apache 2 
> support and other nice bugfixes, is there any chance that Lexer.pm can 
> be finally tweaked to allow component-with-content end tags to contain 
> additional text, eg. </& foo>? (as discussed several times before)
> 
> 
> --- Lexer.pm current
> +++ Lexer.pm proposed
> @@ -489,11 +489,11
> 
>>>>
> sub match_comp_content_call_end
> {
>     my $self = shift;
> 
> -    if ( $self->{current}{comp_source} =~ m,\G</&>,gc )
> +    if ( $self->{current}{comp_source} =~ m,\G</&[^>]*>,gc )
>     {
>         $self->{current}{compiler}->component_content_call_end;
> 
>         return 1;
>     }
> }
> <<<
> 
> --- t/01-syntax.t current
> +++ t/01-syntax.t proposed
> @@ -318,0 +318,19
> 
>>>>
> 
> #------------------------------------------------------------
> +
> +    $group->add_test( name => 'text_in_closing_comp_tag',
> +              description => 'tests that comp call with content can 
> have arbitrary text in its closing tag',
> +              component => <<'EOF',
> +<&| .show_content,
> +   foo => 1,
> + &>\
> +This is the content\
> +</& .show_content>
> +<%def .show_content>\
> +<% $m->content %>\
> +</%def>
> +EOF
> +              expect => <<'EOF',
> +This is the content
> +EOF
> +            );
> +
> +
> <<<
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM.
> Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
> _______________________________________________
> Mason-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mason-devel
> 
> 



-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php