Re: Patch and test to allow component calls

> <%# comment %> does not already work. It is broken.
> 
>   http://www.masonhq.com/resources/todo/view.html?id=537
> 
> Multi-line comments work fine but subject to the same provision that the 
> tag ends with a line break.

Both single-line and multi-line comments work in 1.26 without an ending 
line break. I'm not sure when it was fixed - possibly in the course of 
fixing another bug. We can close the bug after adding tests for it.

>> 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.
> 
> 
> 
> 1. The casual reader is a straw man. Casual readers could make all kinds 
> of wrong assumptions if they base them on someone's components rather 
> than Mason's documentation or code. (And I'm afraid I'm being dense 
> here, but so what if that casual reader concludes that matching 
> enforcement is going on? What harm would that lead to)

Here's an example I've stated before:

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

This it makes it look like foo and bar are filtering different, 
overlapping sections, when of course they are not.

> 4. Why should one not be able to put arbitrary text inside a syntactical 
> tag? Is this not putting the horse before the cart? Surely you should be 
> able to put whatever the language's syntax allows you to put in?

Because it goes completely against people's experience with other 
languages. Minimizing surprise is one of the goals of language design. 
I've never seen a closing tag in any other markup language that can 
contain arbitrary non-matching text. I don't wish to be the first.

> 5. Inconsistency with the rest of the language.
> 
> This is a fair point.
> 
> However I would argue that component calls with content are inconsistent 
> or at the very least have a different nature to other syntax tags in 
> mason. It's half like a component or expression tags and half like a 
> section tag. And yet unlike the component or expression tag, its opening 
> tag is not symmetrical. And unlike the section tag, its closing tag is 
> empty.

That's true, it is a different beast. I'd say we introduced as much 
inconsistency into this tag as we had to.

> Now compare and contrast:
> 
> 
> <& /foo |&>
>   <& /bar |&>
>   ...
>   </&> <%# /bar %>
> </&> <%# /foo %>
> 
> 
> <&| /foo &>
>   <&| /bar &>
>   ...
>   </& /bar>
> </& /foo>
> 
> 
> The latter is more succinct than the commented version. It just plain 
> reads better. I think it's obvious which is actually more meaningful and 
> more useful to a casual mason writer/ lazy perl programmer. 

Yes, I agree, it reads better and is more succinct. But it suggests very 
strongly to that casual mason writer that the parser is doing something 
that it is not. And it allows misleading, out-of-order closing tags to 
be created. Unfortunately the former has to take a back seat to the latter.

Someday we should try to make cwc more like custom tags. For example, 
have one or more configurable directories that contain cwc components, 
and then allow syntax like

   <%NoNewlines>
     ...
     <%Uppercase>
      ...
     </%Uppercase>
     ...
    </%NoNewlines>

With a restricted syntax like this, I would not only allow but *require* 
the closing tag to match the opening tag. Because we'd have the ability 
to require it.

Jon



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