tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ulrich Stärk <...@spielviel.de>
Subject Re: Before I file a JIRA against SupportsInformalParameters
Date Tue, 07 Feb 2012 12:22:01 GMT
I like those proposed changes. Also, they can be gradually introduced with a warning in the
beginning and an exception in later versions.

Uli

On 06.02.2012 20:01, Howard Lewis Ship wrote:
> I'm not saying that the rules are simple or even that there are not
> some ambiguities; I'm more tolerant of ambiguities, as long as they
> only affect edge cases that people are highly unlikely to stumble over
> (*). That being said, is this really a problem, or is it navel gazing?
>
> (*) Actually, if I was to do Tapestry over again, there's quite a few
> places where I would remove things (often, places where I incorrectly
> favored terseness over easy comprehension) : one example is that I
> would probably require that formal parameters be in a namespace. I
> might also remove t:mixins, and require mixins to be configured using
> annotations on a field (labels with @Component).
>
> Perhaps some of these things can be phased in with a new version of the DTD.
>
> On Mon, Feb 6, 2012 at 9:15 AM, trsvax <trsvax@gmail.com> wrote:
>> From what I can tell if you have a mixin and a component that support
>> informal parameters the default namespace parameters will always go to the
>> mixin. This contradicts the documentation which seems to say they should go
>> to the component.
>>
>> Things get more complicated when multiple mixins support informal
>> parameters. I think the first one to render them gets them but I don't think
>> the order in the template has anything to do with the execution order.
>>
>> As far as understanding how things work I think it would be better in this
>> case if the docs were correct because the rule is simple. However changing
>> the code to work as documented could break backward compatibility.
>>
>> At any rate the docs are correct for formal parameters and namespaced
>> parameters but not for default namespaced informal parameters. I think the
>> rule is the first mixin to render them wins. The problem with that is it's
>> difficult to figure out which mixin gets the first chance. The other problem
>> with that rule is the parameters are rendered on the current element. Since
>> mixins can change the current element you never really know where the
>> parameters are going.
>>
>> --
>> View this message in context: http://tapestry.1045711.n5.nabble.com/Before-I-file-a-JIRA-against-SupportsInformalParameters-tp5456349p5460657.html
>> Sent from the Tapestry - Dev mailing list archive at Nabble.com.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org


Mime
View raw message