It looks to me like theres an ambiguity here: I don't think a child
component should be allowed to declare a second parameter, "name" in
this example, that is already defined in a super-class.
On Wed, Feb 11, 2009 at 12:20 PM, Yunhua Sang <yunhua.s...@gmail.com> wrote:
> Hello Howard,
>
> It turns out the error occurs only when the child wants to provide its
> own default binding for a parameter originally defined in parent;
> example:
>
> public class Parent {
> @Parameter
> private String name;
> void setupRender() {
> name.toUpperCase(); // NPE happens here
> }
> }
>
> public class Child extends Parent{
> @Parameter("prop:name")
> private String name;
> public String getName() {
> return "Tom";
> }
> }
>
> Page class:
> public class ChildExample {
> @Component
> private Child child;
> }
>
> Template ChildExample.tml:
> <html xmlns:t="http://tapestry.apache.org/schema/tapestry_5_0_0.xsd";>
> <h3>Test</h3>
> <t:child t:id="child"/>
> </html>
>
> I am sorry for my previous inaccurate information and thanks for
> looking into it.
>
> Yunhua
>
>
> On Wed, Feb 11, 2009 at 2:15 PM, Howard Lewis Ship <hls...@gmail.com> wrote:
>> I'm not aware of anything that's changed in this area; could you elaborate?
>>
>> On Wed, Feb 11, 2009 at 10:56 AM, Yunhua Sang <yunhua.s...@gmail.com> wrote:
>>> Hello all,
>>>
>>> It seems there is no clear document about how to access a parameter
>>> defined in parent component; previous to 5.0.18, I was using the way
>>> of declaring the parameter again in child class and it worked well;
>>> however looks like some changes in 5.1.0.0 broke the way, seems there
>>> is no link between the parameter with same name in parent and child
>>> now.
>>>
>>> The problem is when I am USING a tapestry component, it's such a
>>> comfortable experience; but when I write a sub-class of a component, I
>>> am getting frustrated: a lot of methods are package visible; there is
>>> no clear way for parameter manipulation, a typical question: can I
>>> update an attibute of parameter in parent class? If inheritance is not
>>> a good practice in Tapestry, there should be a document about it.
>>>
>>> Thanks in advance for any help,
>>> Yunhua
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>>
>>>
>>
>>
>>
>> --
>> Howard M. Lewis Ship
>>
>> Creator Apache Tapestry and Apache HiveMind
>>
>> ---------------------------------------------------------------------
>> 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
>
>
--
Howard M. Lewis Ship
Creator Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
