I want to provide user a jpa entity grid component, which will provide
its own griddatasource and hide it to end user; user instead will
provide an ejbql for the entity grid and the component will execute
the ejbql, generate griddatasource, show results in grid. It's a good
example of simplifying/enhancing an existing component.
On Fri, Feb 13, 2009 at 1:57 PM, Robert Zeigler <robe...@scazdl.org> wrote:
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
