On 1/31/07, Scott Swank <[EMAIL PROTECTED]> wrote:
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.
if you can override it why do you need to remove it?
Bottom line is that the relationship of the CSS and the component is pure
infatuation.
components and css work together, of course there will be tight coupling.
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".
heh...windows applications consist of a set of predefined components defined
by the OS. i have plenty of applications where custom components do not skin
properly. they match the colors sure, but they look out of place. we can
provide great skinning support if we will stop letting you create your own
components.
not to mention that html+css is a much more flexible canvas then windows
(before WFP), so i dont think you can draw the parallel very well.
*Summary*
Wicket's component nature introduces the tight relationship with to CSS
and silly convention of housing the CSS in the packages themselves.
is this really that silly? you had to use a datepicker, what did you have to
do? just add a datepicker component. did you have to unzip some zip that
housed datepicker related css+images into some folder in your webapp? no.
why? because datepicker could get them from the jar so there is no
configuration you had to do.
of course if you are going to start overriding css yourself then you have to
do that, but then you probably have your own images to provide anyways. btw,
you dont have to have all your images in the package. nothing is stopping
you from adding an absolute link to your css, and that css having absolute
links to any image urls. of course if you later wanted to reuse this
component in another project you would have to copy over the jar AND any
resources you created as opposed to just dropping in the jar.
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 really depends on how you approach this. my general approach has been to
change the css class of the top level component via attribute modifier or
something else, and then have my global stylesheet include any css for that
component based on that class. take a look at datatable example in
wicket-examples.
It is obvious these components are written with the thought that that their
look is your desired look.
with the exception of modal window i would have to disagree.
-igor
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
-------------------------------------------------------------------------
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
