one thing to keep in mind is that the modalwindow was _not meant_ to be very
customizable. it was meant to be a dropin component that you would use as
is. that is why we put so much work into making it look really good. what we
need to do is to extract an AbstractModalWindow that doesnt have all the
bells and whistles but lets you customize the look more.
also can you not simply do modalwindow.setcssclassname("mine") and then
include an additional stylesheet that looks like one of modal window's but
uses the div.mine as a prefix so it overrides the other styles?
-igor
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
-------------------------------------------------------------------------
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
-------------------------------------------------------------------------
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
