Cool idea, your way really shows how powerful and extendable tapestry
is. Thanks!
On Fri, Feb 13, 2009 at 3:21 PM, Robert Zeigler <robe...@scazdl.org> wrote:
> Interesting. I wonder, though, if you could do this another way, that
> doesn't involve duplicating all of the parameters of grid.
>
> What if you provided a coercion from an EJBQL query to GridDataSource?
> If you want the query to be specifiable as a string in, eg, the template,
> then you could also provide an ejbql binding prefix. The result would look
> something like:
>
> <t:grid source="ejbql:select p from Person p"/>
>
> Now you're just specifying the query string, and ejbql returns the query,
> and tapestry then coerces that (using your query => GridDataSource coercer)
> into your grid data source.
>
> Depends, of course, on how much "extra" functionality you'll be providing,
> so YMMV, but that's how I would approach what you described.
>
> Robert
>
> On Feb 13, 2009, at 2/131:43 PM , Yunhua Sang wrote:
>
>> 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
>
>
> ---------------------------------------------------------------------
> 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
