Hi guys,
Thanks for all your input. I've decided to change my code to use
composition instead of inheritance, though I still remain my opinion:
it would be very nice too that inheritance is perfectly support in
Tapestry.
Now I am going to modify my code... one of my component is a sub-class
of Grid, which has 20 parameters, I have to put near 20 inherit:xxx in
parameters of @Component annotation, hope I won't typo any of them. ;)
Thanks and have a nice weekend.
Yunhua
On Fri, Feb 13, 2009 at 12:27 AM, Robert Zeigler <robe...@scazdl.org> wrote:
>
> On Feb 12, 2009, at 2/126:55 PM , Howard Lewis Ship wrote:
>
>> On Thu, Feb 12, 2009 at 12:58 PM, Robert Zeigler <robe...@scazdl.org>
>> wrote:
>>>
>>> 0) I don't usually extend components; I prefer building things based on
>>> composition. That said:
>>>
>>
>> Which is the point of Tapestry!
>
> Agreed! But our friend isn't using composition, he's using inheritance,
> which tapestry also, technically, supports.
>
>>
>>> 2) This will work iff your parent class also implements a "defaultName"
>>> method that the subclass overrides. Just tried it to be sure.
>>>
>>
>> That's an unintended behavior.
>>
>
> It may be, although I'm not sure why that should be. Consider:
>
> public class Parent {
>
> @Parameter("prop:defaultName")
> private String name;
>
> public String getDefaultName() {
> return "parentdefaultname";
> }
>
> }
>
> public class Child extends Parent {
>
> @Override
> public String getDefaultName() {
> return "childdefaultname";
> }
>
> }
>
> I would fully expect this to work; we specified the property to use that
> supplies the default value, and we override that in the child. I would be
> annoyed if it didn't work. :)
> Since the tapestry convention can be emulated as follows:
>
> @Parameter("prop:defaultName()")
>
> I don't see why the child overriding the parent's defaultName() method
> working is "unintended". It /should/ work. :)
>
>
>>
>>> 3) You can provide getters and setters for the property. Promise. :) But
>>> the
>>> question at stake is /when/ you can access the bound value for supplying
>>> a
>>> default, and in that, you may be correct.
>>
>> Getter & setters will completey work. To the instrumented component,
>> there's no difference between a getter/setter and any other
>> (private) method that accesses the field.
>>
>
>
>>>
>>> Robert
>>>
>>> On Feb 12, 2009, at 2/122:18 PM , Yunhua Sang wrote:
>>>
>>>> Hi Robert,
>>>>
>>>> 2) I tried your way, it doesn't work; it doesn't work even back to
>>>> 5.0.18.
>>>> 3) I don't think the get/set methods would work for parameters; look
>>>> at ParameterWorker class, it's fairly complicated because of the
>>>> implementation of the binding magic.
>>>>
>>>> Thanks,
>>>> Richard
>>>>
>>>>
>>>> On Thu, Feb 12, 2009 at 2:56 PM, Robert Zeigler <robe...@scazdl.org>
>>>> wrote:
>>>>>
>>>>> 1) Since Child extends Parent, it already has a name @Parameter.
>>>>> 2) If you want to provide the default in the child, you can always
>>>>> provide
>>>>> the "default" method:
>>>>> String defaultName() {
>>>>> return "Tom";
>>>>> }
>>>>> 3) Otherwise, access in the child via code is mediated through normal
>>>>> java
>>>>> channels: create a public (or protected) getter and setter in the
>>>>> Parent
>>>>> class.
>>>>>
>>>>> Robert
>>>>>
>>>>> On Feb 12, 2009, at 2/1212:45 PM , Yunhua Sang wrote:
>>>>>
>>>>>> Hi Howard,
>>>>>>
>>>>>> Can you show me in a child component, how to access a parameter
>>>>>> defined in parent by using another way? I cannot find api which isn't
>>>>>> internal about it. By the way, seems it's also diffcult to provide
>>>>>> default binding for a parameter within parent because function
>>>>>> bindParameter(String parameterName, Binding binding) is internal as
>>>>>> well.
>>>>>>
>>>>>> Thanks,
>>>>>> Yunhua
>>>>>>
>>>>>> On Thu, Feb 12, 2009 at 11:10 AM, Howard Lewis Ship <hls...@gmail.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> 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
>>>
>>>
>>
>>
>>
>> --
>> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
