Ok, I dug into the DatePickerSettings and figured out that we can very
easily:
1. Apply our own css that overrides part of the existing css like so:
this.add(HeaderContributor.forCss("../../css/cyllenius_cal.css"));
2. Apply our own css _instead of_ the existing css like so:
settings.setStyle(new ResourceReference(DatePickerSettings.class,
"css/cyllenius_cal.css"));
I'm still researching ModalWindow...
Cheers,
Scott
On 1/31/07, Scott Swank <[EMAIL PROTECTED]> wrote:
Mmm, here's the rather frustrated response from the developer who's been
working on re-skinning DatePicker & ModalWindow to get them to more
seamlessly fit our UI look/feel. Apart from this hitch the demo
implementation has been proceeded so well that we're trying to figure out
what else to do to take up the rest of the week -- so things really are
coming along rather well. I'm open to any/all advice on how best to give
our html/css team reasonably straight-forward access to the look/feel of
components that come packages with their own css.
Many thanks again,
Scott
--------------------------
Team,
Here is my findings and final thoughts on Wicket and CSS for components.
Please let me know if you really want me to get the CSS changed on a
component. I can do just that, but the path to get there isn't entirely
easy. Here are my thoughts:
Firstly, to answer Scotts question "How easy would it be to just sub-class
ModalWindow to one that has our css attached?". The answer is not that
easy. We can subclass sure, but telling wicket to use our own CSS with a
member function call would require changing the code that implements that
component. The components I have seen have a function called setStyle().
The problem is that style assumes you are setting one of its predefined
styles that exist in the package directory.
By convention components have their CSS at the class level (inside the
package) . Worse than that, some times the CSS (or in the case of the
DatePicker) reference a handful of other content like images in the same
class package. In that case you would have to move every referenced piece
of content relative to where you made your changes.
Here are the following ways that make it possible to override Wicket
components CSS:
*1)* Change the source for the desired component(s) to allow better
flexibility in choosing external CSS.
*2)* Override the CSS by either of the following 2 ways:
*a)* Insert a <wicket-head> tag on the page and override CSS
attributes on the desired component page. To find out what the CSS looks
like, you still have to unzip the wicket JAR or wicket-extensions JAR to get
to the CSS:
<wicket:head>
<style type="text/css">div.calendar {position: absolute;z-index:
100000;top:150;left:100;}</style>
</wicket:head>
*b)* Do what I did for the DatePicker, and force the component to add
a new Header to the page (overriding its original components CSS). I was
able to put the CSS in our content directory which in practive gives a
designer the ability to change any CSS properties at will without
redeploying our app:
* add(HeaderContributor.forCss("../../css/cyllenius_cal.css"));*
**
Note: In any case we are going to want designers to be able to access CSS
files without digging into a Java package structure.
*The ModalWindow Problems with styes*
**
I started looking into modifying the ModalWindows CSS just to show we have
control over the component. In order to change its behavior, we would have
to modify Javascript. In order to change its look we need to modify a
tightly coupled component to its CSS.
What has made this a mess is that the ModalWindow has 2 choices, grey and
blue based CSS. By default it uses the blue css (blue borders, etc). In
order for me to override any of the CSS attributes, such as if i want to
have no blue borders and simple black lines, I need to apply choice 1 or 2
above. If we don't modify the source code, we would have to give the
designer the CSS and they would be required to override CSS classes called "
div.wicket-modal div.w_blue" in order to change to new properties. Just
looks ugly to change a property with the word "blue" in it, but its not blue
now its black.
Another silly issue that demonstrates the coupling of a component to its
CSS is that the modal window uses CSS's background-image in for its
blue/grey border. We can only override the image not remove it so that we
simply have a black line. Bottom line is that the relationship of the CSS
and the component is pure infatuation. That intense desire needs to be
broken up in order to achieve the true love that is often seen with the
concept of Windows application - its called "Skinning".
*Summary*
Wicket's component nature introduces the tight relationship with to CSS
and silly convention of housing the CSS in the packages themselves. After
this exercise I am convinced component UI frameworks (at least Wicket) fall
short in allow the developer to "skin" or change the look of a component
with ease. It is obvious these components are written with the thought that
that their look is your desired look. Until this problem can be solved, I
believe this is a major weakness of the component framework.
chris
--
Scott Swank
reformed mathematician
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
