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
