Re: T5: SetupRender before parameters binding in 5.1.0.0-SNAPSHOT?

2009-01-19 Thread Yunhua Sang
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

Re: T5: SetupRender before parameters binding in 5.1.0.0-SNAPSHOT?

2009-01-19 Thread Howard Lewis Ship
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

Re: T5: SetupRender before parameters binding in 5.1.0.0-SNAPSHOT?

2009-01-19 Thread Yunhua Sang
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

Re: T5: SetupRender before parameters binding in 5.1.0.0-SNAPSHOT?

2009-01-16 Thread Howard Lewis Ship
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). >

Re: T5: SetupRender before parameters binding in 5.1.0.0-SNAPSHOT?

2009-01-16 Thread Yunhua Sang
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

Re: T5: SetupRender before parameters binding in 5.1.0.0-SNAPSHOT?

2009-01-16 Thread Howard Lewis Ship
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

T5: SetupRender before parameters binding in 5.1.0.0-SNAPSHOT?

2009-01-16 Thread Yunhua Sang
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

Re: T5: setupRender (named by convention) not called correctly in hierarchical base classes

2008-05-12 Thread Bill Holloway
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

Re: T5: setupRender (named by convention) not called correctly in hierarchical base classes

2008-05-10 Thread Harald Geritzer
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

T5: setupRender (named by convention) not called correctly in hierarchical base classes

2008-05-09 Thread Bill Holloway
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

Re: T5: SetupRender

2007-04-01 Thread Howard Lewis Ship
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

Re: T5: SetupRender

2007-04-01 Thread Peter Beshai
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

Re: T5: SetupRender

2007-03-31 Thread Howard Lewis Ship
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

T5: SetupRender

2007-03-31 Thread Sven Homburg
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