Yeah, missed that. Thanks. On 30/08/2011, at 3:50 PM, Robert Zeigler wrote:
> 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
