I think the example got wiped away in the replies so here it is again:
/**
* This mixin is aplied to all embedded components of the component it is
aplied to.
* example: <t:grid t:mixins="someMixin" /> the mixin is aplied to grid,
gridRows, gridCell etc.
*/
@EmbeddedComponents (@EmbeddedMixin whatever the naming is)
public class SomeMixin
{
}
On Fri, Aug 26, 2011 at 1:13 AM, Kalle Korhonen
<[email protected]> wrote:
>
> 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]
>
