Now I explicitly set prop:defaultSource, get same result. The function
getDefaultSource() seems never get called.
Thanks,
Yunhua
On Mon, Jan 19, 2009 at 2:45 PM, Howard Lewis Ship wrote:
> What is the defaultSource parameter for? Are you using
> prop:defaultSource or inherit:defaultSource? The
What is the defaultSource parameter for? Are you using
prop:defaultSource or inherit:defaultSource? The latter could cause
your NPE.
On Mon, Jan 19, 2009 at 8:22 AM, Yunhua Sang wrote:
> Hi Howard,
>
> I am sorry for this late message; source are as below:
>
> public class EntityGrid extends Gr
Hi Howard,
I am sorry for this late message; source are as below:
public class EntityGrid extends Grid {
@Inject
private EntityProvider entityProvider;
@Parameter(required = true, defaultPrefix = "literal")
private String ejbql;
@Parameter("defaultSource")
private GridD
I would be useful to see some of the code of EntityGrid.
On Fri, Jan 16, 2009 at 3:22 PM, Yunhua Sang wrote:
> The exception is NPE,
>
> On Fri, Jan 16, 2009 at 5:42 PM, Howard Lewis Ship wrote:
>> There shouldn't be a change there. What is the exception (you only
>> included the stack trace).
>
The exception is NPE,
On Fri, Jan 16, 2009 at 5:42 PM, Howard Lewis Ship wrote:
> There shouldn't be a change there. What is the exception (you only
> included the stack trace).
>
> On Fri, Jan 16, 2009 at 2:01 PM, Yunhua Sang wrote:
>> Hello,
>>
>> Is SetupRender phase changed to be in front of
There shouldn't be a change there. What is the exception (you only
included the stack trace).
On Fri, Jan 16, 2009 at 2:01 PM, Yunhua Sang wrote:
> Hello,
>
> Is SetupRender phase changed to be in front of parameters binding in
> 5.1.0.0-SNAPSHOT?
>
> I have a EntityGrid component which is a sub
Hello,
Is SetupRender phase changed to be in front of parameters binding in
5.1.0.0-SNAPSHOT?
I have a EntityGrid component which is a sub-class of Grid and
providing its own GridDataSource; it worked well with 5.0.18. Today I
tried the snapshot but got following exceptions:
org.apache.tapestry
That would be a way to do it, but it's just as easy to put
@SetupRender on A's setup render method. I usually rename it now to
"preRender()" or something. All good.
On Sat, May 10, 2008 at 5:54 AM, Harald Geritzer <[EMAIL PROTECTED]> wrote:
> Bill Holloway schrieb:
>
>
> > I have two abstract co
Bill Holloway schrieb:
I have two abstract component base classes A and B in the base
package. B inherits from A. I have methods literally named
"setupRender" in both. I notice that B's setupRender is called but
not A's. *However*, if I rename A's setupRender() to some other name
and annotate
I have two abstract component base classes A and B in the base
package. B inherits from A. I have methods literally named
"setupRender" in both. I notice that B's setupRender is called but
not A's. *However*, if I rename A's setupRender() to some other name
and annotate it with @SetupRender, bo
Yep, that's exactly what's going on. I need a mechanism so that one
or the other wins. Really, the annotation should win, and the naming
convention should be ignored in this case (that's going to make some
code ugly, but there you have it).
On 4/1/07, Peter Beshai <[EMAIL PROTECTED]> wrote:
Is
Is the reason is because a method named 'setupRender' takes on the same
actions as one annotated with @SetupRender and thus that method is called as
both a BeginRender and SetupRender method?
On 3/31/07, Howard Lewis Ship <[EMAIL PROTECTED]> wrote:
That is a tricky one; it should just be @Begin
That is a tricky one; it should just be @BeginRender since you've gone
to the trouble of labelling it that way.
This is certainly a bug, but a low priority one, with an easy (but
very ugly) fix.
On 3/31/07, Sven Homburg <[EMAIL PROTECTED]> wrote:
Hi folks,
this sample would renderes two times
Hi folks,
this sample would renderes two times in one cycle.
it would be nice, if tapestry notice my error and show me a warning.
public class Start
{
@BeginRender
private void setupRender()
{
System.err.println("Hello from SetupRender");
}
}
--
Mit freundlichem Gruss
hombur
14 matches
Mail list logo