yeah, you got it attach means you attach any resources you might need. a better way to think about it is the opposite of detach() in the model - everyone is familiar with that one. i honestly do not see many use cases for onattach, most of the time i use the lazy loading pattern so all i really need is ondetach(). but i guess it is there for symmetry.
and you are spot on about onbeforerender. -igor On 1/4/07, Jonathan Locke <[EMAIL PROTECTED]> wrote:
actually, it's onBeforeRender. this is a hint for sure to users that you ought to be able to muck with the hierarchy in this method. can you state the proposed semantics in terms of the meanings of the method names? the code movement is not as important as transparency of meaning for users. in other words, what should you put in onAttach and why? and onBeforeRender and why? the answers should be intuitive with respect to the names. in the long run this is more important. my intuition about a method called onBeforeRender is that this would be a place to set up for rendering, including changing the component hierarchy. a method called onAttach would be a place to handle any sort of model stuff dealing with attachment of the page to all its models. igor.vaynberg wrote: > > ive been discussing with johan offline, and here is what we came up with > > there is still a big onattach refactor to do in 2.0. big meaning it will > affect a lot of users. > > the contract for onattach/ondetach was that these methods are called > before > the framework executes any method on the component, but right now onattach > is pretty much onbeginrender with the exception that you are allowed to > modify the component hieararchy. > > take a simple case of clicking link. > > the story should be: > > currently it is > > 1) resolve link component > 2) invoke onclick > 3) invoke onattach > 4) invoke onbeforerender > 5) invoke render > 6) invoke onafterrender > 7) invoke ondetach > > but should be > > 1) resolve link component > 2) invoke onattach > 3) invoke onclick > 4) invoke onbeforerender > 5) invoke render > 6) invoke onafterrender > 7) invoke ondetach > > notice 2 and 3 are reversed as per contract of onattach > but there is a problem with this. suppose link has a compound model, and > inside the link you call getmodelobject() since the model belongs to > link's > parent shouldnt link parent's onattach be called as well? the contract > says > so. > > the only way to guarantee onattach contract is to alter the event chain to > this > > 1) resolve link component > 2) invoke page.onattach > 3) invoke onclick > 4) invoke onbeforerender > 5) invoke render > 6) invoke onafterrender > 7) invoke page.ondetach > > this means that all code that is in onattach needs to move to > onbeforerender > and onbeforerender needs to be relaxed to allow changes in the component > hierarchy, while onattach should not allow modification of hierarchy. this > restriction is necessary so, for example, link's parent doesnt remove the > link before onclick is invoked on it. > > invocation chain for a page set into the request cycle via > setresponsepage() > would be the same but with step 3 taken out. > > the refactor itself will be pretty easy > make onbeforerender final - this will make all overrides visible > move code from overrides to onattach > delete onbeforerender > rename onattach to onbeforerender > create new onattach > > > thoughts? > > > > -igor > > -- View this message in context: http://www.nabble.com/another-big-2.0-refactor-tf2923331.html#a8171948 Sent from the Wicket - Dev mailing list archive at Nabble.com.
