On Thu, Aug 25, 2011 at 3:53 PM, Dragan Sahpaski <[email protected]> wrote: > On Thu, Aug 25, 2011 at 10:07 PM, Thiago H. de Paula Figueiredo < > [email protected]> wrote: >> On Thu, 25 Aug 2011 16:34:34 -0300, Dragan Sahpaski < >> [email protected]> wrote: >> Having the mixin application bound by component id isn't pretty . . . too >> much internal component structure. One t:id change and >> Maybe another, cleaner solution would be to have an annotation on a mixin, >>> that when present applies the mixin on all embedded components of the >>> component the mixin is applied to. Example: >>> What do you think? Maybe this is cleaner as it doesn't say on which >>> components it applies to. Just all embedded components. >>> >> This is a solution, IMHO, way more Tapestry-ish than the previous one. I >> like it. :) Maybe we could also filter by component type, so the mixin >> doesn't need to check all the time which component it was applied. It >> supposes some internal component structure knowledge, but maybe it's a good >> trade-off. > Exactly what I was thinking. @EmbeddedComponents({GridCell.class}) for > example. It even doesn't have to be included in the basic design., it can > be easily upgraded later maybe if people want it. Do you think it deserves a > JIRA i.e. do you see this part of tapestry? I would be happy to produce a > patch.
We can just re-open the existing issue.. but we probably now need yet more comments from others. The difference is that the embedded mixin would be applied (to all child components or) based on type rather than id, would this be an acceptable compromise? Kalle --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
