That's a fair enough expectation, but I believe that the behaviour of page and component properties is this: they may be got during rendering and they may be set by events. They are not set by activation.
If I'm right, then perhaps it should be stated explicitly in the doco to avoid confusion (maybe it already is, but I haven't been able to find it). It wouldn't be right to throw an exception because what you wrote is perfectly legal. Geoff On 30/08/2011, at 4:37 PM, Jens Breitenstein wrote: > Hi Robert, Robert, Geoff, Josh! > > Even if Tapestry's behaviour may be correct from a technical/architectural > point of view by not calling a @Property set-Method this works against what a > developer expects when using @Property + @Parameter (well, at least I did not > expect it). I mean, if it's really a big issue to call a set-Method in case > the @Parameter's value is assigned why not just throw an Exception: "use of > @Parameter + @Property(write = false) + user defined setter for property XYZ > is forbidden, use setupRender instead" when aop-ing the page? This clearly > indicates a certain spec is violated and it's easily solveable by putting the > code in setupRender, totally agreed. > > It's simply a trap for developers and should be solved either calling the > setter or throwing an exception. Not executing a common Tapestry > code-fragment (property setter) and silenty ignoring it for whatever reason > seems odd to me. > > Jens > > > Am 30.08.11 07:43, schrieb Geoff Callender: >> 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
