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
