tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Howard Lewis Ship <hls...@gmail.com>
Subject Re: Before I file a JIRA against SupportsInformalParameters
Date Mon, 06 Feb 2012 19:01:02 GMT
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

Howard M. Lewis Ship

Creator of Apache Tapestry

The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!

(971) 678-5210

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

View raw message