there should be a way to configure services/directives to use jquery or other themes
Opened this issue · 5 comments
jQuery UI declares theme classes for things like menus, menu items etc. Bootstrap etc.
There should be a way to globally configure a provider that can allow the theme to be set (to "jquery-ui" for example) and then in directives like "addVisibilityMenu" they would use these setting to set (optionally) the ui-menu classes.
the UI should still look decent without these classes. but when set, colors and fonts from that theme should be used.
Since there is no way to programmatically import other than defining a variable......
So we either server generate ng-scrolling-table.css with and without theme styles, or we generate a ng-scolling-table.css as a layout CSS and then provide a default -theme.css. This can be optional then if the user includes jQuery CSS
This sounds like a big can or worms to me.
Having a configuration in ng-scrolling-table to knows what classes, such as in the case of JQuery or Bootstrap to spray over the table would also mean we would need to know all of the classes being used for the styling, their correct usage, and any difference between versions of those libraries.
The end user does have the ability to add classes to the table markup or they could create a table level directive the adds the classes to the table elements.
At the moment I am not advocating anything more than -material, but the point I am suggesting is that given "N" configuration/theme styles it should be programmatically settable by the application.
The idea that people will generate their css for their app using our .less I think is a mis-guided approach. We should allow them to override a couple of simple classes (ideally they would do this anyways by overriding the theme for angular-material for example). ie. if we leverage some of the classes (where appropriate) for styling from angular-material, we can use these to style our components without having to override all the specific classes.
So we will need to know the correct use of N number of classes, for M number of themes, for R number of versions of the themes.
No..... we need to know N number of classes for "1" theme - Angular-material. Perhaps "2" if we want to have a backward support for the current theming. Others may be added in the future.... but right now I am targeting the material theme.
I am thinking we need a helper/utility class that given a capability like "tr" or "table" writes out the appropriate classes/style needed. This could have a series of switch statements, having something configured by a provider I am not sure. The point is, to try and make it "easy" for adoption and not make it difficult.