Igor, thanx for very nice explanation. Still one more question for part I do not understand : if I'm in the rendering phase, I would suppose hierarchy is alredy known and I'm just creating the response, right? So why i'm adding for the tag wicket:message this auto component instead of just rendering the message to the response ?
saki > On 11/4/06, Petr Sakar <[EMAIL PROTECTED]> wrote: >> >> > wicket:message tag attributes are replaced at markup load time, but >> > <wicket:message> tags can not be replaced at load time. >> >> So you are replacing them with actual value at render time ? Than it has >> no influence with respect to original question: >> >> If I undestand it correctly, currently component hierarchy is build >> based on markup. How about to do it other way round ? For component >> hierarchy created in your java code lookup the markup ? > > > no, this is not how it works. the hierarchy is built in both places. the > hierarchy you build in your javacode has to match exactly to the hierarchy > you build in markup. > > the problem with components like wicket:message is that they have no java > counterpart, only markup. > > the render process is driven by scanning markup - because that is the only > place where the rendering order of components is defined. > > when we hit a markup component tag ( tag with wicket:id, or wicket > namespace > ) we try to resolve it to its java counterpart before it is rendered. this > is done by resolvers. since the default resolver fails to find the java > counterpart it delegates to other resolves in the chain. the wicketmessage > resolver kicks in. what it does is at render time add what we call an > "auto" > component - these are the only components allowed to be added/modify > hierarchy during the render phase. so wicketmessage resolver adds a label > component to represent the wicket:message tag. then the rendering > continues > and when wicket tries to resolve wicket:message it now finds the auto > component added by the resolver and everything continues as it normally > would. > > -igor >
