Hi, On Thu, Aug 25, 2011 at 8:13 PM, Thiago H. de Paula Figueiredo < [email protected]> wrote:
> On Thu, 25 Aug 2011 14:36:26 -0300, Kalle Korhonen < > [email protected]> wrote: > > On Thu, Aug 25, 2011 at 8:40 AM, Taha Hafeez <[email protected]> >> wrote: >> >>> I had a look at the code. It may not be the best of designs but it >>> certainly is a good resource to learn about the internals of tapestry. >>> Would love you see a blog post about its implementation !! >>> >> >> So far, nobody has stepped up to propose a better design to solve the >> same issue. It may not be the best design, but it's certainly not the >> worst either and it addresses the problem in a generic manner rather >> than for a specific case or component only. The simple suggestions >> that were given do not address the whole problem. Personally, I'd take >> a decent working solution any day over no solution. >> > > As far as I can remember, this was the original problem: "I just want to > read the gridCell's propertyValue, propertyName and the current row object." > Yes. I wanted the contextmenu component, to support the grid without an advice on GridCell, and do it transparently (no advice no bytecode gen). It was specific for a given component and the solution would change the > Tapestry philosophy too much (at least for my taste). Even Dragan itself > agrees that that isn't a good solution. > I wouldn't say it was an issue with a specific component. It was an issue with components that are complex and have embedded components. In the framework itself these components are grid, beaneditor, beaneditform, beandisplay etc. I didn't said I think is a bad solution but I can definitely understand why it would be risky to go into the framework. When using tapestry on a project, it's common to have many components, composed of embedded components, and there isn't an out of the box solution to "advice" them (read extend, transform a bit, add little functionality) and their embedded components. One solution I could think of was the EmbeddedMixin concept (demo<http://dragansah.com/demoapp/embeddedmixinexamples>). 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: /** * 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 { } What do you think? Maybe this is cleaner as it doesn't say on which components it applies to. Just all embedded components. 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 > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > dev-unsubscribe@tapestry.**apache.org<[email protected]> > For additional commands, e-mail: [email protected] > >
