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
