Maybe I'm confused too. It's OK to use @Property together with @Parameter. eg.
http://jumpstart.doublenegative.com.au/jumpstart/examples/component/creatingcomponents It's not OK to use @Property AND a getter or setter. It SHOULD HAVE thrown a runtime exception. if it didn't, then I'd say please file in JIRA. From http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/Property.html : "The annotation will not overwrite an existing getter or setter method; if you put a Property annotation on a field that already has a getter or a setter you will see a runtime exception." As for having Tapestry call the setter during component activation, I'm not keen. The setter is for use by component event requests. To me, sharing it with component activation sounds like a recipe for trouble. Better to stick to setupRender. BTW, I wonder whether the need for, and intention of, getters/setters/@Property should be spelled out more clearly early in the Users Guide? Cheers, Geoff On 30/08/2011, at 12:58 PM, robert baker wrote: > Maybe I'm confused here, but @Parameter and @Property seem to be > orthogonal and not mutually exclusive. > > (from the point-of-view of the component) > @Parameter : data flows from container to this field (and vice versa) > @Property : data flows from contained components to this field (and vice > versa) > > I've had components where both @Parameter and @Property were placed on > the same field, like when I wrapped a Checkbox. (Though, most use > cases where you would put both annotations (like wrappers) seem to be > covered by publishing the necessary parameters.) > > I think, though, the original problem that was put forth of having a > parameter constructor called at component instantiation time sounds > interesting. I know that you can have a parameter programmatically > default if unbound, but I don't think there is a "shadow setter" that > you can wire to get called all the time for property-bound parameters. > > Just my $.02 > > Thanks, > Les Baker > > On Mon, Aug 29, 2011 at 10:52 AM, Taha Hafeez <tawus.tapes...@gmail.com> > wrote: >> Yes, please >> >> On Mon, Aug 29, 2011 at 8:20 PM, Jens Breitenstein <mailingl...@j-b-s.de> >> wrote: >>> Hi Taha, hi Josh! >>> >>> well, that's what my gut feeling told me too. Should I raise a jira issue? >>> >>> >>> >>> Am 29.08.11 16:36, schrieb Taha Hafeez: >>>> >>>> I agree. >>>> >>>> On Mon, Aug 29, 2011 at 7:41 PM, Josh Canfield<joshcanfi...@gmail.com> >>>> wrote: >>>>> >>>>> Sounds like a defect. If there is setter I can't think of a reason that >>>>> @Parameter shouldn't use it. >>>>> On Aug 29, 2011 6:15 AM, "Taha Hafeez"<tawus.tapes...@gmail.com> wrote: >>>>>> >>>>>> @Parameters do not use setters. They create a conduit to set/get the >>>>>> values directly , so setters are never used. >>>>>> >>>>>> You can look at the code of ParameterWorker for details >>>>>> >>>>>> you can always use setupRender to setup things >>>>>> >>>>>> On Mon, Aug 29, 2011 at 6:16 PM, Jens Breitenstein<mailingl...@j-b-s.de> >>>>> >>>>> wrote: >>>>>>> >>>>>>> Hi All! >>>>>>> >>>>>>> I tried to use a combination of @Property and @Parameter. >>>>>>> >>>>>>> >>>>>>> @Property(read = true, write = false) >>>>>>> @Parameter(required = true) >>>>>>> private String _myParam; >>>>>>> >>>>>>> >>>>>>> unfortunately it seems to be impossible to "intercept" a set in such a >>>>> >>>>> case >>>>>>> >>>>>>> // ---->> NEVER CALLED >>>>>>> public void String setMyParam(final String param) >>>>>>> { >>>>>>> _myParam = param; >>>>>>> // do more... >>>>>>> } >>>>>>> >>>>>>> >>>>>>> Is there any reason this is not allowed? >>>>>>> >>>>>>> >>>>>>> Jens >>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >>>>>>> For additional commands, e-mail: users-h...@tapestry.apache.org >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Regards >>>>>> >>>>>> Taha Hafeez Siddiqi (tawus) >>>>>> http://tawus.wordpress.com >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >>>>>> For additional commands, e-mail: users-h...@tapestry.apache.org >>>>>> >>>> >>>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >>> For additional commands, e-mail: users-h...@tapestry.apache.org >>> >>> >> >> >> >> -- >> Regards >> >> Taha Hafeez Siddiqi (tawus) >> http://tawus.wordpress.com >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org >