In the recent past I've changed markup loading to use MarkupFragment instead of MarkupStream and I think it is more or less ok. The change as such don't provide any benefits right now (except Markup Attributes in the constructor), but is a pre-requisite for the change to the modified render process to come (probably V3). All changes so far are more or less invisible for most users. One vision associated with MarkupFragments is that within a components constructor the hierarchie of component can be build and that it remains stable during the render phase (component hierarchy unmodifiable during the render phase). This requires to replace all resolvers with I call for now loaders. Loaders are invoked when a component loads a new markup (via the cache). The various loaders may scan/analyze the markup and if necessary create and add components. Headers (<wicket:head>) was what I picked first. I changed the code, all junit tests are successful and than I started playing with the form example. Two issues: a) when you change the language the markup must be reloaded and b) when you click the save button the same page gets displayed with additional infos at the bottom. What is common to both use cases is that the component hierarchy remains the same, but the markup changes. Re-loading the markup from disk is not the problem, but when does it happen? It happens during the render process. And because the reloaded markup might have different wicket:head tags (or any other auto-component), they are removed at the end of the render process which means they _must_ be rebuild when the markup gets loaded. Two possible solutions: a) stay with adding auto components at render time b) make the *Targets responsible to re-create the autocomponents and only than render the page. Solution (a) questions a little bit our vision and (b) will end up with where does the render process start and where does it end. Solution (a) has another drawback: if we really want to achieve a 1:1 relationship between markup and component hierarchy than there will be scenarios where components are inside <wicket:head> and when we remove the wicketHead container at the end of the render cycle, that it removes the inner component(s) as well. Any thoughts?
Juergen
