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
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
