Tapestry will only throw an exception if there's a getter and "read" (from @Property) is true, or there's a setter and "write" is true. If "write" is false, then tapestry doesn't attempt to generate a setter, and you're fine. In the case of the original post, "write=false", so no exception was thrown.
Robert On Aug 30, 2011, at 8/3012:43 AM , Geoff Callender wrote: > 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 >> > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
