Correction. Step #1 is on the DatePicker itself, while step #2 is on the
DatePickerSettings. Dumb cut/paste mistake.
On 1/31/07, Scott Swank <[EMAIL PROTECTED]> wrote:
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
--
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
