tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kalle Korhonen <kalle.o.korho...@gmail.com>
Subject Re: Extending the mixin concept (just a bit)
Date Wed, 03 Aug 2011 23:01:51 GMT
I'm afraid that Dragan might have been a little too exhaustive
describing the issue :) The meat is at the end of his post - what if
you could invoke mixin's methods not only on the invocation of the
component's own render methods but also its child component render
method invocations? You could also think of it as a mixin applying
mixins to the child components of a component. The documentation
clearly states that "mixins may not, themselves, have mixins"
(http://tapestry.apache.org/component-mixins.html), but is this a
technical limitation or a design decision? It could be useful whenever
you have a well-defined composite component, like with Grid,
BeanEditor, etc. Dragan's use case makes sense to me, but I'm
wondering if anybody can reason why this might not be such a good idea
or see any better solutions for the problem.


On Sat, Jul 30, 2011 at 2:10 AM, dragan.sahpaskix@gmail.com
<dragan.sahpaskix@gmail.com> wrote:
> Dear Developers,
> As part<http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/dragansah/1>of
> GSOC 2011 I'm doing (as well as some other things) a contextmenu mixin
> that should work with the t5 grid. The mixin works fine on other components
> but the t5 grid is tricky because I want to apply a context for the menu for
> each cell (and row) i.e. provide a way to show different content based on
> the cell (and row) value.
> I have read threads on the list where when someone is trying to extend a t5
> component like the grid with something the grid was "not intended to do",
> the comment on the list can be make a new component etc. but IMO it would
> be awesome if t5 allowed doing things like this.
> I have the t5 grid integration with the contextmenu mixin working, but it
> involves some changes in GridCell and AbstractPropertyOutput, and a change
> that introduces another GridOutputContext service (similar to
> PropertyOutputContext) that don't break anything (tests don't fail) but are
> only there for components like the contextmenu that want to pull cell data
> from the grid rendering cycle, to be used outside in a mixin for the grid
> or similar. I want to make a patch for the contextmenu component but IMO you
> (the developers) won't be so thrilled in commiting such changes, and I can
> say I would agree with you if this was the case.
> So please read on while I make a proposal for extending the t5 concept of
> mixins just a bit.
> In t5 the semantics of the components is generally  exposed as @Parameter s,
> public methods, render cycles and events. While this component model is
> very convenient and powerful it doesn't (out of the box) have a way to
> expose the structure of the component to the outside world. OK you can argue
> that what's inside the component is a private implementation, and should not
> be changed by an outside component for example, but please consider this
> example: The t5 grid component has gridRows and gridCells. This simple fact
> about grid's structure should not change (IMO) and should be possible to be
> exposed outside the grid, for components or mixins (like the contextmenu)
> can use it.
> Not to be too long I don't have some ground breaking suggestion for some
> radical change but I have a simple suggestion, that if I get positive
> comments from the devs would like to work on right away.
> I suggest that a mixin applied on a component should be able not only to
> have the component's render phase events, but also have the render phase
> events from embedded components in that component.
> Example:
> Let's have <t:grid t:mixins="contextmenu" />
> ContextMenu.java (mixin)
> void afterRender() {
> ...
> }
> // not possible now
> void afteRenderFromGridCell(){
> ...
> }
> I guess one downside would be that users start making mixins that
> use embedded components that change (or get removed) in the future, but
> maybe we can control this by having something like
> @ExposeRenderEvents(GridCell.class, GridRows.class) or something similar.
> Does anyone consider this extension worth having?
> Cheers,
> Dragan Sahpaski

To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org

View raw message