I was just trying to modify the styles for the pagination links but realized it wasn’t working because my custom css file is linked in the browser before the extension’s css file. So I can not override css rules.
Perhaps yii should link extension/core css/script files before application ones? Is that possible?
Perhaps I should just not use the core css file at all, but it would be nice to not have to.
Is it possible to configure widgets in the config file? This is not working:
<?php 'components'=>array( //... 'CLinkPager' => array( 'class'=>'CLinkPager', 'cssFile'=>'pager.css', ), ),
Perhaps it is not made to do that. But perhaps it should? It would be really nice if I could define the cssFile in the main config so I don't have to keep repeating it in every place I put the widget. And if I also defined the cssFile within the widget settings, it should override the main config. What do you think?
Your customized css may be placed after the <title> tag. 
Ok. I decided just to use a totally separate css file instead instead of over-riding attributes.
What do you think about the second suggestion though? in the second comment (http://www.yiiframework.com/forum/index.php/topic,631.msg3309.html#msg3309)? I think it's a really good idea.
For instance what if you want to use a date picker extension. Most people will want to have many custom settings for these related to look and operation. Most people will also have many instances of these widgets across many forms and views. And most of the time, most of the settings will need to be the same. So I think it will help people from repeating themselves if you could define widget settings in the app config file.
First let me point out a drawback of your suggestion. It will increase the size of app config. Imagine we have many widgets to configure in a complex project. And they will all take the precious config space (app config has to be loaded for every request. so we should keep it small).
There’s a better idea, which is known as skin. The idea comes from asp.net and is implemented in Prado. It was mentioned earlier in Yii forum. Due to performance concern, I postponed it and am waiting to see if there are more requests for this.
A skin is essentially an array that can be used to configure a type of widget. Each widget can have a few skins, each identified by a skin ID (or a default skin if no skin ID). Skins are stored as files (just like app config) in a theme folder.
Now the fun part, the following code will apply a skin to the pager:
<?php $this->widget('CLinkPager', array('skin'=>'pink', ...)); ?>
The corresponding 'pink' skin (stored as CLinkPager.php under the currently active theme folder) is:
return array( 'pink'=>array( 'cssFile'=>'/path/to/pink.css', // other initial properties ), );
I like that idea even better! Sounds like a good plan. You can almost argue that components should also be configured like that too (in separate files).
There's a cost. That, when we create a widget, we will need to look for the skin file. That's why the skin has not been implemented by far. We should probably limit this to widgets only because this is theme-centric.
Should I create a ticket for this?
Yes, please. Set it for 1.1a milestone, though.
It doesn't seem to allow me to set the milestone…?
Try again. Thanks!
I still can't find anywhere to set the milestone… am I missing something?
I just realized that non-member user cannot specify those fields. Sorry.
I created the ticket already. Thanks!
I don't understand why it would need to 'look' for the skin file actually (do you mean directory searching like file_exists() ?).
If you called:
<?php $this->widget('CLinkPager', array('skin'=>'pink', ...)); ?>
It would then
<?php //of course this exact code won't work but it's to give the idea $config = include 'application.views.skins.CLinkpager'; //tada: $config['pink']
Instead of looking for the file, we can add one more "mapping" file, that contains pairs like::
array( 'pink' => 'path/to/pink', .... );
an it will just check if there is such key. If so - load file. If not - instantiate widget as usual.