no we can't simply change the order of visitChildren. It is used everywhere.
Juergen On 6/13/06, Michael Day <[EMAIL PROTECTED]> wrote: > 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 > >>>>>> Wicket-user@lists.sourceforge.net > >>>>>> https://lists.sourceforge.net/lists/listinfo/wicket-user > >>>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> Wicket-user mailing list > >>>>> Wicket-user@lists.sourceforge.net > >>>>> https://lists.sourceforge.net/lists/listinfo/wicket-user > >>>>> > >>>>> > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> Wicket-user mailing list > >>>> Wicket-user@lists.sourceforge.net > >>>> https://lists.sourceforge.net/lists/listinfo/wicket-user > >>>> > >>> > >>> > >>> _______________________________________________ > >>> Wicket-user mailing list > >>> Wicket-user@lists.sourceforge.net > >>> https://lists.sourceforge.net/lists/listinfo/wicket-user > >>> > >>> > >> > >> > >> > >> _______________________________________________ > >> Wicket-user mailing list > >> Wicket-user@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/wicket-user > >> > > > > > > _______________________________________________ > > Wicket-user mailing list > > Wicket-user@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/wicket-user > > > > > > > > _______________________________________________ > Wicket-user mailing list > Wicket-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wicket-user > _______________________________________________ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
