Ahh...That is a very different scenerio. I'll update the jira issue. I'm not sure it's doable but we'll see. I can't see it being possible to do if this costs us performance wise (ie extra checks for each property), but if there's a reasonable way to do it without hurting performance I might try..
On 10/5/06, andyhot <[EMAIL PROTECTED]> wrote:
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]
-- Jesse Kuhnert Tapestry/Dojo/(and a dash of TestNG), team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
