Jesse, I initially thought the exact same thing... But upon reading again the issue, i think peter is requesting something else, i.e. throw an exception when someone accesses a persistent property while in a page attach listener.
But i don't see this getting changed either... http://tapestry.apache.org/tapestry4.1/UsersGuide/events.html explains this behavior. Jesse Kuhnert (JIRA) wrote: > [ http://issues.apache.org/jira/browse/TAPESTRY-1111?page=all ] > > Jesse Kuhnert resolved TAPESTRY-1111. > ------------------------------------- > > Resolution: Invalid > Assignee: Jesse Kuhnert > > Normally I'd be all for providing better/more intuitive defaults but don't > think I agree in this instance. > > Tapestry doesn't do anything special to these properties, they are > initialized by the jvm like any other member. If you have an int with no > value specified it'll be -1. For any non native types it's usually null I > think. > > In many instances this may actually be the desired behavior for people to > have. > > As always, if you have a compelling argument for doing it your way the door > is always open/tickets can be re-opened...I'm just not seeing it with the > arguments given so far. > > >> Throw an exception when trying to access an uninitialized property >> ------------------------------------------------------------------ >> >> Key: TAPESTRY-1111 >> URL: http://issues.apache.org/jira/browse/TAPESTRY-1111 >> Project: Tapestry >> Issue Type: Improvement >> Components: Core >> Affects Versions: 4.0 >> Reporter: Peter Eastman >> Assigned To: Jesse Kuhnert >> >> If you do not specify a default value for a property (e.g. with >> @InitialValue), it gets initialized to a default value selected by Tapestry. >> This creates lots of opportunities for confusion and bugs. I suggest that >> instead, the property should be marked internally as "uninitialized". If >> you attempt to get its value while it is in that state, it should throw an >> exception. Looking up a property before its value has been set is almost >> always an error. It is much better to immediately alert the user so they >> can fix the bug, rather than letting their program appear to work, but >> misbehave in some possibly subtle way. >> This applies to any situation where you try to access a value that is not >> currently available. For example, if you try to access a persistent >> property inside pageAttached(), it should throw an exception rather than >> simply returning null. >> > > -- Andreas Andreou - [EMAIL PROTECTED] - http://andyhot.di.uoa.gr Tapestry / Tacos developer Open Source / J2EE Consulting --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
