> 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 ? > AttributeModifier must be attached to a Component, but the markup can > be associated with multiple component instances. Hence it must be > resolved at render time. > Just look at all the *Resolver to find out which components are > automatically added at render time > Magic is something we try to avoid. Magic is difficult to understand > by users and make the code more difficult to maintain. Simple and > straight forward is what we should aim for. > > Juergen Sorry for using word 'magic'. I'm trying to find out if such straight forward approach is possible - to create pages by specifying component hierarchy only in java code, and have markup only for components where it is needed. saki > > On 11/4/06, Petr Sakar <[EMAIL PROTECTED]> wrote: >> > that wont work, some components such as <wicket:link> and >> <wicket:message> >> > only exist in markup >> >> Igor, >> thank you for your answer. >> >> From api doc: >> wicket:message="value=key" would replace or add the attribute "value" >> with >> the message associated with "key". >> >> I would expect it is implemented using AttributeModifier, not component. >> >> With wicket:link example you are right, but can be solved (you would >> have >> to add the component in code (or do some magic). >> >> Can you please give me other examples as well - I'm a bit curious and >> would like to find out if it is really impossible. >> >> Thanks >> saki >> >> > >> > -igor >> > >> > >> > On 11/3/06, Petr Sakar <[EMAIL PROTECTED]> wrote: >> >> >> >> Question / Idea: >> >> 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 ? >> >> >> >> saki >> >> >> >> >> > >> >> >
