On Thu, Aug 25, 2011 at 10: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.
>
> @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.
>
> If it gets loose into the wild, what does that mean for our ability to
> refactor and rewrite core components? or even third party components?
> Every time you decide something as minor as a name change for an
> embedded component you have to worry that all of the users of your
> system are now broken.
>
> Breaking encapsulation should not be standard practice.
>
OK I can see the problem here. But what do you think about the newly
proposed concept to be able to apply a mixin to the component, and all of
its embedded components. Its touching the inner structure, but I think it is
just enough to be acceptable. After all as Kalle said using advices and
mixins on render methods assumes knowledge on what is going on in the
implementation of a component.
Cheers,
Dragan Sahpaski
>
> >>> 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
> the cells. Perhaps adding a Parameter for a GridRenderListener
> interface:
>
> GridRenderListener {
> renderRow(MarkupWriter writer, Object row);
> renderCell(MarkupWriter writer, Object cell);
> }
>
> It'd probably be cool to make Grid and it's supporting components
> generic as well, but that's not relevant...
>
> Josh
>
> 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]
>
>
