On Thu, Aug 25, 2011 at 1:21 PM, Josh Canfield <[email protected]> wrote: > Depending on the internal implementation of an object makes your code > brittle. Depending on the internal implementation of a Component makes > your code brittle.
Agree, lots of other things make your implementation brittle as well. > @EmbeddedMixin is on par with using reflection to grab out private > fields. Minor changes to that class/component and your code may not > work anymore. Right, similarly to advices and aop in general. > Breaking encapsulation should not be standard practice. Agree. >>>> So far, nobody has stepped up to propose a better design to solve the >>>> same issue. > Refactor Grid so that you can get access to the before/after render of Forget the grid for a moment - is your proposed solution to refactor all composite components where you'd like to apply similar behavior? The problem of course is the same as why advices and mixins are so useful - because the original components are not necessarily in your control, but with these constructs you can alter their original behavior rather than re-implement similar functionality or modify the original component for your purposes. Kalle > On Thu, Aug 25, 2011 at 12:34 PM, Dragan Sahpaski > <[email protected]> wrote: >> 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] >>> >>> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
