I've been fighting this problem for a couple of months now and I thought I had it solved until last Thursday when I started writing a lot of test cases. I personally think the Tapestry's don't mind the man behind the curtain is the correct approach and it almost always does exactly what I would expect which is why the problem is frustrating me. I also understand the desire for backward compatibility and at this point I think that is the correct direction to head.
Part of my problem is I'm having problems nailing down exactly what the problem is but I think I understand it pretty well now. So I'll try and summarize it. I think if the code worked as documented there would not be a problem. If the component and a mixin both define a parameter with the same name, then the component wins: the component's parameter will be bound, and the mixin's parameter will be unbound. But this is not what happens when supports informal parameters is set. Without informal parameters I can namespace my mixins and be assured I can pass parameter reliably to my mixins because fw.type is not the same as foo.type so Tapestry can do the right thing. With informal parameters the problem is I can have a parameter called type. Now it is not clear where type should go. Should it go to the component the fw mixin or the foo mixin? What if multiple mixing and the component support informal parameters? Should it go to all of them. Since there are two mixins that have type as a parameter is it even an informal parameter? So my specific problem is I want to add a mixin called fw to every component and I want to be able to pass it a parameter, but if informal parameters are supported it's not clear to me how to pick a name that will not conflict with any parameter a user decided to add into the mix. Since many of the base components support informal parameters this is not really an edge case. If there is a way I'd like to know what it is. So is this problem worth solving? I'd say yes but perhaps I'm in the minority. If it is worth solving there are a few ways to do it. 1. Make it work as documented. This is not backward compatible. 2. I think if you add an argument to @SupportsInformalParameter(namespaceOnly=true) then it could be fixed. This argument would required all the parameters to this mixing be namespaced informal or not. My plan now is to name my parameter fwtype and hope no one else tries to use that name. Not the best solution but from a practical standpoint I think it will work. So I think there is a workaround for this. So I think there is a problem but if no one sees it that way I think I understand the problem well enough to work around it. Thanks Barry -- View this message in context: http://tapestry.1045711.n5.nabble.com/Informal-Parameters-considered-harmful-tp5589569p5591716.html Sent from the Tapestry - Dev mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
