Wicket, HTML or XHTML ?

[pierre . goiffon]

Hello,
As a Wicket beginner, I was wondering if there are any contra-indication 
to generate some HTML 4.01 Strict instead of any XHTML 1.0 version 
(transitionnal or strict) ? 
I tried to simply add an HTML 4.01 strict doctype to my html files, and it 
seems to work fine (thought in development mode I have in the source the 
xmlns:wicket in the body tag and all of the Wicket XHTML tags - going to 
deployement mode an they disappear)
Is there anything I must take care of ? Wicket use a namespace server-side 
so... ?
Best regards,
P. Goiffon

Re: Wicket, HTML or XHTML ?

[pierre . goiffon]

Erik van Oosten <[EMAIL PROTECTED]> wrote on 11/09/2008 15:06:05:

> For Wicket the doctype is not needed, so do what you like. Just remember
> to keep it in XML syntax.

Reading this I wonder if I just have to produce well-formed html files (
http://www.w3.org/TR/REC-xml/#sec-well-formed), or taking care of the 
points listed in the XHTML 1.0 recommandation in chapter 4 (
http://www.w3.org/TR/xhtml1/#diffs) ?

I wanted to generate HTML instead of XHTML to get rid of the mandatory 
Appendix C (http://www.w3.org/TR/xhtml1/#guidelines) rules.

> There is only one ceavat: you should always
> write  instead of ,

OK

Re: CSS navigation menu & autolink

[Pierre Goiffon]

No answers...

The question is how to make automatic linking have an effect on the A 
tag and its container LI tag, knowing that both of them are part of a 
custom wicket component.


Anyone ?


[EMAIL PROTECTED] wrote:

Hello all,

I'm really new in the object world in general and using Wicket 
particularly, so please excuse if I'm missing something... I've 
googled around but maybe I didn't use the good keywords.



So here's my question !

I'm building a navigation menu for my web application. There are 3 
different levels, the higher one is linking to different Wicket pages. 
My top level menu is html coded like this :



Menu Item 1
Menu Item 2
Menu Item 3


Notice the class="current" on the selected page.

I've already created the following code (see below), but was wondering 
if there are any means to use the Wicket autolink feature ? It would 
be far more simplier... The difficulty I see is to modify the  tag 
on the selected link ? Thanks for advices !




// LayoutAuthenticated.html
...

Libellé menu1

...



// LayoutAuthenticated.java

protected MenuItem menu1aOpt1;
protected MenuItem menu1aOpt2;
protected MenuItem menu1aOpt3;

public LayoutAuthenticated() {
...
List menu1aList = new ArrayList();
menu1aList.add(menu1aOpt1 = new MenuItem("menu1aItem", true, 
"menu1a.Opt1", Opt1.class));
menu1aList.add(menu1aOpt2 = new MenuItem("menu1aItem", true, 
"menu1a.Opt2", Opt2.class));
menu1aList.add(menu1aOpt3 = new MenuItem("menu1aItem", true, 
"menu1a.Opt3", Opt3.class));

add(new ListView("menu1a", menu1aList) {
@Override
protected void populateItem(ListItem item) {
item.add(item.getModelObject());
}
});
...
}



// MenuItem.html


/>





// MenuItem.java

private String keyLabel;
private Class lienClass;
private WebMarkupContainer menuItem;
private BookmarkablePageLinkWithoutDisabledMarkup link;

public MenuItem(String wicketId, boolean isActive, String 
keyLabel, Class lienClass) {

super(wicketId);

setLienClass(lienClass);
setKeyLabel(keyLabel);

setRenderBodyOnly(true);
add(menuItem = new WebMarkupContainer("menuItem"));
menuItem.add(link = new 
BookmarkablePageLinkWithoutDisabledMarkup("link", lienClass));

Label label;
link.add(label = new Label("label", new 
ResourceModel(keyLabel)));

label.setRenderBodyOnly(true);
}

public void setLienClass(Class lienClass) {
this.lienClass = lienClass;
}

public void setKeyLabel(String keyLabel) {
this.keyLabel = keyLabel;
}

public void setActive() {
menuItem.add(new SimpleAttributeModifier("class",""));
link.setEnabled(true);
}

public void setInActive() {
menuItem.add(new SimpleAttributeModifier("class","current"));
link.setEnabled(false);
}



// BookmarkablePageLinkWithoutDisabledMarkup.java
// (just to keep my  tag on selected links)

public  
BookmarkablePageLinkWithoutDisabledMarkup(String id,

Class pageClass) {
super(id, pageClass);
}

@Override
protected void disableLink(ComponentTag tag) {
tag.remove("href");
}



// Opt1.java

public class Opt1 extends LayoutAuthenticated {
public Opt1() {
menu1aOpt1.setInActive();
}
}



// Opt2.java

public class Opt2 extends LayoutAuthenticated {
public Opt2() {
menu1aOpt2.setInActive();
}
}



// Opt3.java

public class Opt3 extends LayoutAuthenticated {
public Opt3() {
menu1aOpt3.setInActive();
}
}



// Wicket application init()
// (don't need the default  tags around the selected link label)

...
getMarkupSettings().setDefaultBeforeDisabledLink("");
getMarkupSettings().setDefaultAfterDisabledLink("");
...


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Validating HTML 4

[Pierre Goiffon]

Hello,

I'm working as a developper for a software company that build some 
products using Wicket 1.4 (1.4.17 for the moment being).


I'm trying to improve accessibility in our online survey product. The 
first thing I did was to check our pages with the W3C validator 
(http://validator.w3.org), as it's the first step to go on.


The web pages are sent with an html strict doctype with url : indeed we 
have no interest in using XHTML as those pages will be sent over the web 
so to any king of user agents, and don't want to deal with all the 
things you have to care about when sending XHTML in text/html to older 
browser (like the recommandation C appendix).


I noticed some problems that are caused by Wicket, mainly because it 
works in the xml way. As I can't see any mean to override those 
behaviors I'm asking here for any idea :) I looked at the 1.4.19 sources 
but can't see improvements on these subjects.


Here are the different problems I saw :

- When using ResourceReference the link tags are closed in the xhtml way 
: . Should be  in HTML.

It seems to be hard coded in HeaderResponse#renderCSSReference()

- In Form components Wicket adds hidden inputs. They are also closed in 
the xhtml way. Seems to be hard coded in Form#onComponentTagBody() and 
Form#appendDefaultButtonField().


- DataTable : a SPAN is always added in the TD and TH. For lots of 
reasons we need to insert DIV (block level) elements in the cells of a 
custom DataTable based component, and so the html hierarchy looks like :

TH > SPAN > DIV > ...
TD > SPAN > DIV > ...
It's not valid to have a block level element inside an inline one.
I can't see how to change those span to div (DataTable.html and 
HeadersToolbar.html).If it's not possible to get rid of that extra html 
container in that wicket component, would it be at least ok to change it 
to a div element ?


- DataTable : the TFOOT node is always sent to the client, even if it's 
empty. In that last case, the html code is invalid in html.


Thanks for your answers !

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Validating HTML 4

[Pierre Goiffon]

Hi,

Le 10/11/2011 09:29, Martin Grigorov a écrit :
> So you say that  is valid but  is not.

I thought that any self closing tag was invalid in any html version, 
html 4 as of html 5.

But the validator is ok with self closing br and link in html 5, and the 
html 5 draft recommandation says very clearly self closing tags are 
allowed for "void elements" (which br and link are part of) - just to 
remember : http://www.w3.org/TR/html5/syntax.html#syntax-start-tag, point 6.

For HTML 4, the self-closing tags are not valid in the validator (br as 
link), and the recommandation is pretty clear to my opinion : 
http://www.w3.org/TR/html4/intro/sgmltut.html#didx-element-3.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Validating HTML 4

[Pierre Goiffon]

Le 10/11/2011 10:33, Martijn Dashorst a écrit :
> While technically closing a  tag is
> considered a validation error (I tried the html validator of w3c, see
> below), in practice the HTML 4.01 standard is really crippled, as are
> the other HTML standards from that time.

Can you provide us some details of what you meant by cripple ?
Are you thinking about parsing of whatever wicket server-side issues ?

Using HTML 4.01 strict and CSS 2.1 is pretty nice since some years now : 
the browsers switch to their standards rendering mode, and except for 
the different IE css bugs it would be a pretty cool world for web 
developpers. Of course sending pages without any doctype is a nightmare 
and should not be done.

> There is no reason what so
> ever not to use HTML5 doctype and rules

I'd be happy to aknowledge, but your statement lacks some arguments ? 
Can you give some reasons to be confident about that ?


Reading that thread I have different options :

- Keep everything like it is.
This is not so good, considering we aim to make our products certified, 
and we know some of our clients will only use our products if their IT 
gives a green light. For both checks, lots of validation errors will 
give very bad feelings ! For exemple in a sample page I made, we add 
more than 60 validations errors, and now I'm blocked for the reasons I 
talked about just above 40. This is still a lot !

- Update to HTML 5
Only feasable if all browsers including IE6 renders HTML 5 and CSS as of 
HTML 4 strict + CSS 2. I'm not aware of that area, Martijn Dahorst I'd 
be please if you could give some informations and url where I can learn 
more !
But anyway, I don't think we'll just have to change the doctype... And I 
don't think HTML 5 will give us any benefits for now on (I hope in a 
near future, but for now we have to deal with IE 6+...). So that seems 
like a lot of efforts just to have valid Wicket pages.

- Suggest again to skip any self closing tags and replace the SPAN with 
some DIV.
Of course I'm not aware of everything in Wicket, but I don't think this 
will break to much existing apps : I'm pretty confident everyone uses 
HTML 4 (and maybe a litlle html 5 ?) instead of XHTML, and replacing 
span by div would only break css selectors, if any (and there shouldn't 
be so much of them !).
But Martijn, you were talking about an xhtml validator in wicket 
(Message-ID: 
), 
it's something out of my scope, can you please give more details ?

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Validating HTML 4

[Pierre Goiffon]

Le 10/11/2011 14:58, Martin Grigorov a écrit :

I thought that any self closing tag was invalid in any html version,
html 4 as of html 5.

But the validator is ok with self closing br and link in html 5, and the
html 5 draft recommandation says very clearly self closing tags are
allowed for "void elements" (which br and link are part of) - just to
remember : http://www.w3.org/TR/html5/syntax.html#syntax-start-tag, point 6.

For HTML 4, the self-closing tags are not valid in the validator (br as
link), and the recommandation is pretty clear to my opinion :
http://www.w3.org/TR/html4/intro/sgmltut.html#didx-element-3.



I guess you mean: "Such empty elements never have end tags."
 has no end tag.


Do you refer to the HTML 4 recommandation I pointed, and the phrase :
"Some HTML element types have no content. For example, the line break element 
BR has no content; its 
only role is to terminate a line of text. Such empty elements never have end 
tags."

It says no end tags, and don't say you have to "self-close" the start tag. The 
others recommandations states clearly an empty element can (for html 5) and 
must (for xhtml) has a "/" caracter in the start tag ending.
If we admit what is admit is what is written, then the HTML4 recommandation is 
clear on this point, right ?

Re: Validating HTML 4

[Pierre Goiffon]

Le 10/11/2011 16:11, Martin Grigorov a écrit :
> I just tested  in Wicket 1.5 quickstart and it produced 
>  (no auto close of the start tag).

Can you explain your test ?

I'v just downloaded the wicket 1.5.2 package (zip version with sources) 
and I see that HeaderResponse#renderCSSReference(String url) calls at 
last HeaderResponse#internalRenderCSSReference(), and that method output 
a link tag with a "/" at its ending (so ).
So I would guess ResourceReference are still rendered with self closing 
link tags ?

Maybe a solution not too hard to implement would be to add a method like 
getTagEnding(), not final, that could be easily overridable ?
For HeaderResponse#renderCSSReference() for exemple :

 public void renderCSSReference(String url, String media)
 {
 if (Strings.isEmpty(url))
 {
 throw new IllegalArgumentException("url cannot be empty or 
null");
 }
 if (!closed)
 {
 List token = Arrays.asList(new Object[] { "css", 
url, media });
 if (wasRendered(token) == false)
 {
 // some code ...
 getResponse().println(getTagEnding() + ">");
 markRendered(token);
 }
 }
 }

 protected String getTagEnding() {
 return " /";
 }

With that solution I'd be able to create an override to HeaderResponse 
that would just change the getTagEnding() return value.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Validating HTML 4

[Pierre Goiffon]

Le 09/11/2011 11:23, Martin Grigorov a écrit :
 - DataTable : a SPAN is always added in the TD and TH.
>>> Override DataTable component and provide your own MyDataTable.html.
>>> The .java code will just call super constructors.
>> As said before, I don't feel very confident in duplicating wicket code and
>> change a very little detail in it. Is there a way to change those span to
>> div in future versions of Wicket ?
> Sure. File a ticket in Jira.
> We cannot change it in 1.5.x because it may break silently apps in
> production. So it will have to wait Wicket.next.
>

I've just created issue 4224 :
https://issues.apache.org/jira/browse/WICKET-4224

Thanks !

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Wicket 1.4.20 : error message "Access denied to (static) package resource"

[Pierre Goiffon]

Hello,

After upgrading from Wicket 1.4.19 to Wicket 1.4.20 I get exceptions in 
TinyMCE. We're using the Wicketstuff integration.
When opening TinyMCE lightboxes I get exception like :

org.apache.wicket.markup.html.PackageResource$PackageResourceBlockedException: 
Access denied to (static) package resource 
com/interview/tool/wicketstuff/tinymce/themes/advanced/image.htm. See 
IPackageResourceGuard

It works perfectly in Wicket 1.4.18 or 1.4.19, but when updating in the 
pom to the 1.4.20 version we get that exception.
I can't figure what ticket could be related in the 1.4.20 changelog 
(https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310561&version=12317570)

Any idea ?
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Wicket 1.4.20 : error message "Access denied to (static) package resource"

[Pierre Goiffon]

Martin and Antoine, thanks very much for your quick answers, it solves 
of course my problem !
SecurePackageResourceGuard has already a lot of common extensions, and 
it's easy to add the ones you eventualy need !

Martin, I still can't see in the 1.4.20 changelog 
(https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310561&version=12318545)
 
what ticket could be related to this change ?
And nothing in the version announcement : 
http://wicket.apache.org/2012/03/12/wicket-1.4.20-released.html.

For us this is a major regression and I just discovered it by chance... 
I recommend to have a word maybe in the 1.4.20 announcement, and change 
the title of the related 1.4.20 ticket to be more comprehensive ?
Thanks !
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Wicket 1.4.20 : error message "Access denied to (static) package resource"

[Pierre Goiffon]

Le 21/03/2012 12:24, Martin Grigorov a écrit :
> As I said this change is due to a security related problem.
> An official announcement will come very soon.
> We haven't sent it so far because we wanted to give you some time to
> upgrade to 1.4.20/1.5.5 before making the problem public.
> Sorry for the troubles!

I understand your concern about revealing details of a security problem. 
As a wicket user, I'd rather be aware of the details when the version is 
out, and make my own decision beceause almost everytime you have to 
choose the best compromise between changing your code and the risk your 
application is exposed to. Upgrading and finding out that you have to 
change your code without knowing why, you just feel inconfortable and 
fear that there are lots of things you miss, that will brings you some 
extra bugs.
But this is a long debate :)

Thanks anyway very much for your almost immediate help, it was much 
appreciate !

Best regards,
P. Goiffon

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

renderHead() / wicket:head page / component order

[Pierre Goiffon]

Hi,

We recently upgrade to Wicket 1.5. One of the major concern during that 
migration was to deal with the new order of the header render strategy.
I see this is defined in AbstractHeaderRenderStrategy#get(), and reading 
https://issues.apache.org/jira/browse/WICKET-4000 I understand the 
reason of this choice : to be able to replace a parent contribution.

But this is a big problem when you deal with css, because in your 
supages / panels / components you will insert specific properties that 
are meant to override global ones defined in the page... and to do so 
the css properties in the subpage / panel / component must be inserted 
in the head AFTER the page css declaration.

For exemple I am just dealing with a problem in a page hierarchy like 
the one below :
pageA : adds mycss.css using renderHead and a ResourceReference
pageB : adds 6 lines of css to change the behavior in wicket:head
pageC : adds 1 line of css to override a margin in wicket:head

The only solution I see with wicket 1.5 is to create css files for the 
properties in page B and page C and adds them in each renderHead() using 
an implementation of AbstractResourceDependentResourceReference.
This is just a nightmare, and impacts also the user (3 css files to 
download instead of 1 !).

Are there any mean to do better ?
If not, as I think we need both to render in the header before or after 
the parent, maybe there should be a method for each order ? Like 
renderHeadBefore() / renderHeadAfter() ?

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: renderHead() / wicket:head page / component order

[Pierre Goiffon]

 >> We recently upgrade to Wicket 1.5. One of the major concern during that
 >> migration was to deal with the new order of the header render strategy.
 >> I see this is defined in AbstractHeaderRenderStrategy#get()
(...)
 >> For exemple I am just dealing with a problem in a page hierarchy like
 >> the one below :
 >> pageA : adds mycss.css using renderHead and a ResourceReference
 >> pageB : adds 6 lines of css to change the behavior in wicket:head
 >> pageC : adds 1 line of css to override a margin in wicket:head

> There are some improvements in this area in Wicket 6.
> Please read http://wicketinaction.com/2012/07/wicket-6-resource-management/
> for more information. Pay attention to PriorityHeaderItem and setting
> custom header item comparator. Header contributions from 
> are represented with org.apache.wicket.markup.head.PageHeaderItem.

Thanks very mutch Martin, very interesting !
Your blog have a lots of very nice posts like this one, I'm going to 
read lots of them really carefully ! I'm very happy to find such a 
resource as documentation is not the strongest Wicket highlight !

Getting back to my concern...

PriorityHeaderItem is a nice answer to serve the most generic resources 
(in my exemple, mycss.css) : clean and simple.
Looking at the Wicket 6 classes in your sample project 
(https://github.com/martin-g/blogs/tree/master/wicket6-resource-management) 
I also see a CssContentHeaderItem that allows to add CSS without adding 
a link and an extra resource to download for the UAs : cool !

But as a developper I still see some issues :
- It's not very convenient to write static css in the Java code instead 
of simply leave it in the html file in a wicket:head block. In prev 1.5 
version it was a very simple way to add static client side code !
- Just using a PriorityHeaderItem wouldn't be enough, cause I need the 
header contribution to be in the order A / B / C. I would need to write 
a custom comparator... And it wouldn't be that nice because in my case 
page A and page B are in a different project than page C - this latter 
is the only one to be in the same project as the wicket application 
class. The custom comparator would also certainly become quite unusable, 
dealing with too many specific cases ?

For the 1.5 branch a simple solution I see would be to let the 
IHeaderRenderStrategy be defined by the Wicket application class. So 
every one would be able to choose what is his most wanted preference : 
be able to override parent renderHead() methods 
(ChildFirstHeaderRenderStrategy), or have a very simple mean to insert 
cascading client side static code (ParentFirstHeaderRenderStrategy).

I you use a ParentFirstHeaderRenderStrategy and still need to override a 
parent renderHead() in a specific component, you could still move the 
parent code to an overridable method right ? Like :

parentClass {
public void renderHeader(..) {
doStuff();
}

public void doStuff() {
...
}
}
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: renderHead() / wicket:head page / component order

[Pierre Goiffon]

Hello !

Le 22/07/2012 21:39, Martin Grigorov a écrit :
 For exemple I am just dealing with a problem in a page hierarchy like
 the one below :
 pageA : adds mycss.css using renderHead and a ResourceReference
 pageB : adds 6 lines of css to change the behavior in wicket:head
 pageC : adds 1 line of css to override a margin in wicket:head
>>
>> But as a developper I still see some issues :
>> - It's not very convenient to write static css in the Java code instead
>> of simply leave it in the html file in a wicket:head block. In prev 1.5
>> version it was a very simple way to add static client side code !
>
> In Wicket 6 this is still valid. The only change is the order in which
> the content in s found in base/sub page, base/sub panels
> is rendered.
> The order is now consistent - no matter if you contribute the CSS via
> markup ( or ) or via code (in .java).

I didn't understand your statement ? Particularly "the order is now 
consistent".

My problem was originally about the delivery order of wicket:head 
contributions that was changed in wicket 1.5.
Reading your statement I understand wicket:head do still render parent 
first in Wicket 1.5 but in Wicket 6 renders child first, like the other 
Java way (renderHead() right ?), so I guess I don't understand well what 
you wrote ?

> Wicket defines two simple rules:
> 1) component-first contribution - if you use a library that provides
> Wicket components (e.g. WiQuery) then the components will contribute
> first and then your page. This way you have the last word what CSS
> rules to apply. I.e. you can override WiQuery's default CSS rules.
> 2) child-component contributes after its parent - when you use
> #renderHead(IHeaderResponse) you are in control to call
> super.renderHead() at the top  of the method body or at the bottom.
> Most of the time developers put it at the top. You don't have the
> control for that for  though. Here Wicket contributes
> first the parent's markup and then the child's one.

When you define a simple page strategy like in my problem, you could 
have static css overrides and wants to deal with it in the css order, 
that means most specific last. And those css overrides (like 
".main-section { margin-top: 0;}") are quite static so wicket:head is a 
perfect place for them : quick to find, quick to write, quick to modify.
Having to move them to the java file isn't that awful, but a little more 
heavier. Plus in Wicket 1.5 I don't have CssContentHeaderItem so the UA 
will get a css link for each contribution, and that is very bad.

We were using WiQuery in previous versions of our product, back then we 
served a global css for wiquery component. I've just search how we were 
dealing with WiQuery css but can't find anything. Indeed the last 
WiQuery jar we used, the 1.2.3 version, don't contains any .css file ?
Anyway we have lots of shared components, but we do have a common 
abstract class for each application, and so we are able to serve a 
common css file.

> In org.apache.wicket.markup.renderStrategy.AbstractHeaderRenderStrategy#get()
> method there is intentionally "hard" way to switch the header
> contribution strategy. It uses a system property named
> 'Wicket_HeaderRenderStrategy' which value may be the fully qualified
> name of the strategy to use.
> org.apache.wicket.markup.renderStrategy.ParentFirstHeaderRenderStrategy
> is the one that has been used in Wicket 1.4- and is considered
> deprecated.
> So you can set this system property in your MyApp#init() but I cannot
> guarantee for how long it will work.

Very good to know, thanks a lot !

Not sure though how to fix the property ? Is it by inserting the 
following line in the application init() method :
System.setProperty("Wicket_HeaderRenderStrategy","org.apache.wicket.markup.renderStrategy.ParentFirstHeaderRenderStrategy");
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: renderHead() / wicket:head page / component order

[Pierre Goiffon]

Le 26/07/2012 10:29, Emond Papegaaij a écrit :
> Hi Pierre,

Hi Edmond, thanks for your answer !

> First of all, I strongly recommend you do not use a different
> HeaderRenderStrategy.

Yes, Martin made it very clear that ParentFirstHeaderRenderStrategy is 
deprecated.

> Second, I suggest you use Wicket 6, because consistent resource ordering in
> Wicket 1.5 is nearly impossible.

Reading this made me smile : we use Wicket for a while now, and 
upgrading major versions was almost always painfull. The most difficult 
time we add was with the migration to 1.5... So I don't think just a few 
week after fixing our first version using Wicket 1.5 and still having to 
deal with bugs related to the migration, my team would agreed to upgrade 
to Wicket 6, that is still in beta stage :)

For now on we dealt with the resource order problem mainly using a 
custom implementation of AbstractResourceDependentResourceReference.

> HeaderResponseTest in Wicket 6 gives a good demonstration of the order of
> resources. It shows that normal resources are rendered child-first, starting
> at the root of the class inheritance hierarchy. If you change nothing, the
> order will be B, C, A (A is last, because its header contribution is via
> renderHead). To move A to the front, you wrap it in a PriorityHeaderItem, and
> you should be done.

Where can I find this HeaderResponseTest class ? I don't have it in the 
wicket-core 6.0.0-beta3 avalaible via Maven ?
Is it this one :
http://svn.apache.org/repos/asf/wicket/trunk/wicket-core/src/test/java/org/apache/wicket/markup/html/internal/HeaderResponseTest.java

In Wicket 1.5 if I do nothing, resources contributed in renderHead() 
would be rendered in this order : C, B, A.
I'm surprised the order would be B, C, A in Wicket 6 ? Why so ?

In my exemple I need to define 2 priorities, because the css that was in 
the B page wicket:head needs to be before the one in page C, and the css 
linked in page A must be the first resource to be rendered. Could 
PriorityHeaderItem answer this need ?

> In Wicket 6, all headers are
> rendered child-first, except PriorityHeaderItems, which are rendered parent-
> first.

I see that in the PriorityHeaderItem Javadoc. Does that means if I add a 
PriorityHeaderItem in page A, and another in page B, the one in page A 
(parent page) will be rendered before page B (child page) ?


Another question : can you confirm me there are no equivalent in Wicket 
1.5 for the Wicket 6 CssContentHeaderItem ? Said otherwise, in Wicket 
1.5 can I serve content in java directly in the head ? I don't want 
every css contributions to be added with link tags and makes the 
browsers do one more download...
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: renderHead() / wicket:head page / component order

[Pierre Goiffon]

Le 26/07/2012 20:54, Martin Grigorov a écrit :
>> Another question : can you confirm me there are no equivalent in Wicket
>> 1.5 for the Wicket 6 CssContentHeaderItem
>
> https://github.com/apache/wicket/blob/wicket-1.5.x/wicket-core/src/main/java/org/apache/wicket/markup/html/internal/HeaderResponse.java#L59

Thanks Martin, I shouldn't have missed that :/
It's a correct workaround for my specific problem with a hierarchy of 3 
pages !

When serving the css in page B and C with IHeaderResponse#renderCSS() 
they are correctly inserted after the main css that is added in 
renderhead() method in page A. Plus B and C are inserted in the correct 
order.

When serving the static css of page B and C with render:head as it used 
to be, they are served in the correct order (B then C) but before the 
page A main CSS.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: renderHead() / wicket:head page / component order

[Pierre Goiffon]

Hello,

> Wicket 6 final won't take long.

Good to know !

> I'm not sure about the Wicket 1.5 ordering, but in Wicket 6, header items are
> rendered child-first in the component hierarchy. For every component,
>  is rendered first, followed by the header contributions in the
> Java code. Within a component's class hierarchy, rendering starts at the base
> class (as long as you put the super call at the top).
(...)
> You seem to be confusing class inheritance with the component hierarchy. There
> is no component hierarchy between pages, only class inhertance. Header items
> are rendered top-down in the class inheritance chain. The reason that you will
> need PriorityHeaderItem for the resource from page A, is that you contribute
> it from Java, and it will therefore end up after the wicket:head
> contributions.

Well understood for the rendering order in both cases (components 
hierarchy and class inheritance), thanks thanks to your very complete 
summary !

But one more question though : why rendering wicket:head (in the markup 
file) contributions before renderHead() (in the java file) contributions ?
Seems to me that what you'll put in wicket:head will certainly be some 
king of static code, like the css in my problem (so like this : 
.myclass{ padding: 0;} or $(document).ready(function(){ 
$("#login").focus();});). This code could need some library (JQuery for 
exemple), and you'll serve that resource using a ResourceReference so 
using renderHead() right ? If wicket:head is served before renderHead() 
then you'll have a problem...
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: renderHead() / wicket:head page / component order

[Pierre Goiffon]

Le 31/07/2012 08:33, Emond Papegaaij a écrit :

But one more question though : why rendering wicket:head (in the markup
file) contributions before renderHead() (in the java file) contributions ?


With these things you just have to make a decision. Both orders are equally
valid. You use wicket:head for minor adjustments in styling, others use
wicket:head to contribute the css files and do the adjustments in renderHead.
The idea was, that with this order, it is always possible to override any
static wicket:head contribution from the Java code. Personally, I try to avoid
wicket:head as much as possible and render everything from renderHead. This
gives you the most flexibility.


Right :)

Many thanks for all your answers !

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org