BTW: The reason this is a big deal is previewability. Currently I have to maintain two copies of my CSS directory (and associated images): one in webapp and one in the classpath. It makes development rather difficult and error-prone.
When editing my Page, I need a CSS directory in the classpath. When testing the application I need a CSS directory in webapp.
Gili
Gili wrote:
Ack. I was hoping you wouldn't say that :(
Jon, independantly of CSS support, this is a perfect use-case for why I think we need a generic resource static URL generator. It would allow me to reference any package-scoped resource across the entire application. Right now we only do this for Images but from an implementation point-of-view I think the behavior should be identical for *all* static resources (be they images, CSS files, etc).
Gili
Eelco Hillenius wrote:
Gili wrote:
I think I understand your expanded example now but it still does not explain to me how I go from Page-related paths to Application-relative paths for the CSS pages.
That is, if I have Page.java, Page.html, Page.css and Page.html refers to Page.css, when the Page is actually rendered, the CSS path (specified in Page.html) is invalid because it refers to Page.css relative to the HTML -- which is fine for previewability but breaks during actual Application rendering. Do you understand what I mean? I mean, in your example you use "foo.css" for previewability and "myDefaultStyle.css" at render-time (I guess you dynamically generate this CSS file?), but who is responsible for assigning "myDefaultStyle.css" its unique resource path? It looks to me like you are manually doing this and assuming it won't collide with anything else. I'm looking for an automated safe mechanism like we have for SharedResource, StaticImageResource, or Image (I forget who holds the URL nowadays).
What I'm doing in the example is different than what you think. I'm just pasting in plain strings, no references to resources or anything else. Thus, myDefaultStyle.css has to be in your webapp dir, not in your package. So, no, you can't package them. That's something for 1.1. Now for 1.0, you have to do a bit more work yourself, which in this case means have all css files you reference in your webapp dir.
Eelco
Gili
Eelco Hillenius wrote:
Ok, I expanded the example with some more documentation.
The HeaderContributor interface is part of the example. What I describe here is something you could build yourself; just an example.
Sure, you can associate CSS markup with a Page directly. Just use:
<html> <head> <link rel="stylesheet" type="text/css" href="foo.css"></link>
You have to know which stylesheets you use on that page though, so the whole thing I put my example for is, when you create reusable components, that need some seperate css file(s), that you don't (want to) know about when you create your main page.
Eelco
Gili wrote:
I'm looking at the example and I'm not exactly sure I understand what is going on. So you have your main Page, and then you seem to be including a ListView component whose model consists of the CSS filename.
I don't understand what HeaderContributor is all about (I can't find it in the Javadoc or CVS), nor do I understand how this mechanism causes Wicket to map the CSS filename to a globally-stable URL. Perhaps you could shed some more light on this?
Also is there a way to associate a CSS markup with a Page in a direct fashion? Or must I really use a ListModel/View?
Thanks, Gili
Eelco Hillenius wrote:
See the wiki: http://wicket.sourceforge.net/wiki/doku.php?id=user:include_css_references_for_components for one way to do this.
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
