Why do you want to remove t:mixins? I never use @Component just do it in the tml file. I like that feature and won't it affect the oh mighty precious compatibility?
On Feb 6, 2012, at 2:01 PM, Howard Lewis Ship <[email protected]> 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 <[email protected]> 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: [email protected] >> For additional commands, e-mail: [email protected] >> > > > > -- > 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 > http://howardlewisship.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
