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: > > Hi, >> > > Hi, Dragan! > > One solution I could think of was the EmbeddedMixin concept >> (demo<http://dragansah.com/**demoapp/embeddedmixinexamples<http://dragansah.com/demoapp/embeddedmixinexamples> >> >**). >> > > 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. Cheers, Dragan Sahpaski > > > -- > Thiago H. de Paula Figueiredo > Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, > and instructor > Owner, Ars Machina Tecnologia da Informação Ltda. > http://www.arsmachina.com.br >
