Re: Patch and test to allow component calls
Jonathan Swartz <[email protected]>
| Newsgroups | gmane.comp.web.mason.devel |
|---|---|
| Message-ID | <[email protected]> |
>>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.
>
>
> The users *want* two syntaxes. I think we should listen.
>
> They want it for (1) self-documentation, and (2) syntax-validation to
> verify the end tag matches what they think it should.
>
> I think we can give them that with trivial parsing if we just match
> verbatim up to the first comma. That means in the slightly non-trivial
> case of <& $foo, %ARGS &> we are matching q{$foo} instead of the contents
> of $foo. For complex cases such as <& fee($foe,$fum) &> we should
> recommend that they use </&> instead, since it will be there for backward
> compatibility anyway.
I'm in favor of the full end tag syntax if it can actually be used for
syntax-validation (as opposed to the arbitrary comment text that Alex is
pushing for).
The Mason compiler already makes an explicit distinction between literal
strings or Perl expressions in <& &> and <&| &>. From
http://masonhq.com/docs/manual/Devel.html#components_that_output_html:
comp_path may be a literal string (quotes optional) or a Perl
expression that evaluates to a string. To eliminate the need for
quotes in most cases, Mason employs some magic parsing: If the
first character is one of [\w/_.], comp_path is assumed to be a
literal string running up to the first comma or &>. Otherwise,
comp_path is evaluated as an expression.
So how about this: If a <&| &> tag contains a literal string as defined
above, then you can use either </&> or </& LITERAL>, where LITERAL is
the exact literal they specified. Otherwise, they can only use </&>.
This is mostly as John suggested, except that we don't let them use </&>
for expressions.
I'm assuming that literals are vastly more common than expressions in
<&| &> tags, so this should give Alex what he wants in most cases.
Except that he won't be able to stick long diary entries in his </&> tag.
What do you think?
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