Depending on what you're trying to do, you may be able to accomplish what you want with a mixin, and avoid having to duplicate any parameters at all. On a project awhile back, for example, I wrote a "filter" mixin for grid so any grid could have filtering applied to it just by adding the mixin. What is it you're trying to do?

Robert

On Feb 13, 2009, at 2/1310:58 AM , Yunhua Sang wrote:

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


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Reply via email to