I haven't looked at visitChildren, but couldn't we reverse the order? It makes more sense for the child pages to add their contributions last, right? Either way, I think I'm going to abandon the markup inheritance and simply use a border only. I haven't had time to ensure this works as expected, but I assume it will.
Michael Day On Jun 12, 2006, at 5:33 PM, Juergen Donnerstag wrote: > I was thinking about the first approach. Ok that doesn't work. > Unfortunately I can not think of any other means to change the order. > Wicket internally (HtmlHeaderContainer.renderHeaderSections) uses > MarkupContainer.visitChildren() which determines the order. Currently > that method is private final. Presuming we make it protected you could > extend from HtmlHeaderContainer and implement your own "visitChildren" > which takes another order into consideration. > >> From a "visitChildren" point of the ordering is correct, isn't it. It > goes down the component hierarchy and the border is a child of > ChildPage. > > Unfortunately I can not think of any other easy solution. It must > apply to bordered pages only and not simply to any Border added to a > Page. Border components which make a bordered page are identified by > Border.setTransparentResolver(true). So another option, though I > regard it a suboptimal solution, would to modify the > HtmlHeaderContainer.renderHeaderSections implementation to change the > visitChildren implementation to search for a Border (bordered page) > first, than call visitChildren but exlude the border. That doesn't > sound like good programming, does it. Any other idea? > > Juergen > > On 6/12/06, Michael Day <[EMAIL PROTECTED]> wrote: >> If I understand you correctly, that wouldn't help. Do you mean that >> I should just use markup inheritance with no borders? I can't do >> that because I need to be able to change the border implementation at >> runtime. >> >> Or do you mean that the BaseBorderPage would just add a border? If >> so, that's what I tried =). The problem with that approach is that >> the header contribution is in opposite order from what I expect. In >> your example, Page's header contributions are listed above >> BaseBorderPage's header contributions. This means that I can't >> override stylesheets that were included in BaseBorderPage's header. >> >> On Jun 11, 2006, at 10:41 PM, Juergen Donnerstag wrote: >> >>> And why don't you create a BaseBorderPage -> BasePage -> Page. It >>> would be separated than >>> >>> Juergen >>> >>> On 6/11/06, Michael Day <[EMAIL PROTECTED]> wrote: >>>> Yes, basically I have a border for all pages, but I add it in my >>>> BasePage class. I did it this way so that I could easily change >>>> border implementations in one class. >>>> >>>> I think I'm just going to abandon that method, and just add the >>>> border on each page with a custom BorderFactory or something. >>>> >>>> On Jun 11, 2006, at 3:54 AM, Juergen Donnerstag wrote: >>>> >>>>> a) you can not change the order. >>>>> b) Not sure I understood your component hierachy already and >>>>> that is >>>>> probably because you are using markup inheritance and the idea of >>>>> bordered pages for the very same page? Not that it is forbidden >>>>> but >>>>> people are usually using only either one with markup inheritance >>>>> being >>>>> preferred as easier to understand/use. >>>>> >>>>> Juergen >>>>> >>>>> On 6/11/06, Michael Day <[EMAIL PROTECTED]> wrote: >>>>>> How can I change the ordering of header contributions? I have >>>>>> Border >>>>>>> ParentPage > ChildPage. The ParentPage has <head>, while Border >>>>>> and ChildPage have <wicket:head>. The problem is that the >>>>>> Border's >>>>>> header contributions show below the ChildPage contributions. I >>>>>> would >>>>>> expect the other way around since, in my case, ChildPage is the >>>>>> most >>>>>> specific page. I'm trying to include a stylesheet in ChildPage >>>>>> that >>>>>> overrides a previous stylesheet that was included in the Border. >>>>>> >>>>>> That was longwinded and hard to explain. Hopefully it made >>>>>> sense. >>>>>> >>>>>> Michael Day >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Wicket-user mailing list >>>>>> [email protected] >>>>>> https://lists.sourceforge.net/lists/listinfo/wicket-user >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Wicket-user mailing list >>>>> [email protected] >>>>> https://lists.sourceforge.net/lists/listinfo/wicket-user >>>>> >>>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Wicket-user mailing list >>>> [email protected] >>>> https://lists.sourceforge.net/lists/listinfo/wicket-user >>>> >>> >>> >>> _______________________________________________ >>> Wicket-user mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/wicket-user >>> >>> >> >> >> >> _______________________________________________ >> Wicket-user mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/wicket-user >> > > > _______________________________________________ > Wicket-user mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/wicket-user > > _______________________________________________ Wicket-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-user
