Hi all,
thanks for your precious hints. For this time @InjectContainer is
sufficient for my needs.
Its all about self written input field components, which render behavior
is controlled by user permissions determining if a user is permitted to
read/write fields by generic/reflective checks of his permissions for
certain entities and their fields.
Its working now as long my form components not rendered in loops or
grids :-)
Greetings, Erich
Am 16.02.2015 21:49, schrieb Chris Mylonas:
@InjectContainer is the way to go.
Have a 10 minute read on the OSI 7 Layer model for data communications
as a reference point if you need one.
e.g. Each layer knows the layer above and below it, like parent and
child.
It's a proven mechanism of keeping things "encapsulated" and if you
have custom @Service tapestry artifacts you can still do the object
oriented things.
If you have dozens of components it'll be a little bit of a refactor,
but __totally__ worth it compared to alternate approaches.
Mylo's 2cents :)
Cheers
Chris
On Tue, 17 Feb 2015 07:43:18 +1100, Erich Gormann
<e.gorm...@gormann.de> wrote:
OK,
I'm not experienced in the InjectContainer annotation, but it seems
that one have to write it on each embedded component?
I have to figure out.
The original intention was that the component's container must not be
mentioned anywhere, even not in an annotation.
Von Samsung Mobile gesendet
-------- Ursprüngliche Nachricht --------
Von: Thiago H de Paula Figueiredo <thiag...@gmail.com>
Datum:13.02.2015 21:03 (GMT+01:00)
An: Tapestry users <users@tapestry.apache.org>
Betreff: Re: How to get container inside self written component
On Fri, 13 Feb 2015 17:26:25 -0200, Erich Gormann
<e.gorm...@gormann.de>wrote:
Hi Thiago,
Hi!
I see what you mean, but I did not want to manipulate the
containercomponent, but only wanted to look up if a certain (self
written)annotation is present on it and then let the embedded
component to docertain things.
According to my opinion that would be a nice way to get
informationabout the container component without knowing it in the
embeddedcomponent and without make the unnecessary work for other
developers towrite one more parameter besides all other ones.
I can not see why an additional parameter is the recommended way here.
Now that you've given the whole picture, specially the annotation
part,now it makes sense to use @InjectContainer. But remember
thatannotation-level classes are *not* live-reloaded, so, once you
put orremove the annotation, this check won't work. It can be made to
workindirectly, implementing and contributing a
ComponentClassTransformWorker
that calls setMeta("someKeyYou'llCreate", "true") in the
component'sComponentModel when it has the annotation. To query that
in the innerocmponent, you can @Inject ComponentResources and use
thegetContainer().getComponentModel().getMeta(String key).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
