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.
>>> 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]
