On 8/30/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > I think what you want can be compared to what Tapestry supports.
the reason this works ok for tapestry is because component hierarchy is very flat. 99% usecase is you have a page and you add a bunch of components to it, one level deep. wicket is different, the hierarchy is completely arbitrary and can change at runtime. i dont see tapestry supporting a single-page application where you just swap panels as the main means of workflow. in order to support that we really do need to know which component is inside which other one? the tree is also great for advanced processing where you can use visitors to mutate it arbitrarily or conviniences such as compoundpropertymodel. given some effort what we can do is derive the hierarchy from html layout during render/some sort of preprocessing, and still allow for those visitors, but the problem is that the hierarchy mutates, visibilities change, etc. so you would always need a render/html traversal if you wanted to have the hierarchy available, and that would get very very messy. is this all doable? probably. the problem is we wont know cons until we have actually built it, and it will take a tramendous effort for us to do that. the abandoned 2.0 branch took about half a year of work, if not more. we believed the constructor refactor was a Good Thing because it solved problems. however, once we got there we noticed certain things were no longer as easy or as flexible, or even possible. it created more cons then pros so we had to throw all that away. i have the same feeling about this. right away it is obvious that repeaters wont work because they _do_ need to have the same id in the markup (but their path is unique because of the hierarchy). things that add components at runtime wont have access to the hierarchy right away, etc. while in the beginning it does seem like a pita to keep it in sync, after a little bit it becomes second nature and you dont even notice it. my 2c -igor
