Mind you open an RFE for it than.
It is probably not a big deal to implement (Wicket makes it realy
easy). But we'd need a vote from the core committers to add yet
another wicket tag
Juergen
On 6/24/06, Michael Day <[EMAIL PROTECTED]> wrote:
> The problem is that you have to specify it in your ja
The problem is that you have to specify it in your java code. I
prefer to have the flexibility of only specifying it in the markup.
This allows me to use styles more effectively as I only have to
specify the CSS link in the markup files that require it. It's not a
big deal (it's just a p
I haven't understood how that is different. Lets say this is a Page's markup
(copied from previous mail)
>
>
> My Template
>
>
>
>
>
what is the difference between the static css link and a dynamic one like
add(HeaderContributor.forCss(MyChildPage.class, "MyChildCSS.css"));
Both
I finally got around to this again, and I don't particularly like the
idea of using the following to add CSS contributions last:
add(HeaderContributor.forCss(MyChildPage.class, "MyChildCSS.css"));
The problem is that I'm trying to specify a CSS override file for
only *some* of my "styles/vari
I saw the proposed solution. Thanks very much. I haven't had time
to try it out yet, but it sounds like it will work perfectly.
Thanks,
Michael Day
On Jun 16, 2006, at 3:32 AM, Davy De Durpel wrote:
>
> I don't know if you still follow this thread. Maybe you're waiting
> for an
> alert.
I don't know if you still follow this thread. Maybe you're waiting for an
alert. That's why I reply to one of your mails so that you are notified
about the propose solution further down the thread.
--
View this message in context:
http://www.nabble.com/header-contribution-ordering-t1768566.html
I will add a HowTo during the weekend.
--
View this message in context:
http://www.nabble.com/header-contribution-ordering-t1768566.html#a4896178
Sent from the Wicket - User forum at Nabble.com.
___
Wicket-user mailing list
Wicket-user@lists.sourcefo
Didn't think about that. But you are right of course. The pages header
contributions are added last. The only disadvantage I can think of is
that you can not develop self-contained wicket components/widgets as
you would always need to add this ref to the page. Well, not even that
is true. getPage()
Well no. It would only solve my problem. How selfish of me to propose
something like that ;-)
I felt so sorry this morning that I have searched for a real solution to
Michaels problem, and guess what I found it.
All that needs to be done is add something similar to this at the end of the
child p
I don't think it solves Michaels problem, does it? May be should an
attribute to wicket:head, e.g. order="first" and allow to set the
preferred order with the Page (or the Page header container).
Juergen
On 6/14/06, Davy De Durpel <[EMAIL PROTECTED]> wrote:
>
> I ran into a similar problem and m
I ran into a similar problem and my workaround was to use the "id" attribute
for overwriting a style.But that is not a clean solution since it makes
the CSS files very hard to read and you don't always have full control of
the "id" attribute value.
Maybe we need an extra optional wicket tag t
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? Eit
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 e
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.
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
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 imple
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.
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 inheritanc
How can I change the ordering of header contributions? I have Border
> ParentPage > ChildPage. The ParentPage has , while Border
and ChildPage have . The problem is that the Border's
header contributions show below the ChildPage contributions. I would
expect the other way around since,
19 matches
Mail list logo