FR - Indicate Default CSS

[PointsWell]

When you create any object within AIM you do not need to set the CSS class or style unless you want to change it from the default. What would be better would be if the default class and styles that are going to be applied were declared within the Config Tool, that way you would be able to copy a style from one object without having to dig about in the web console.

[customaware]

+1

[PointsWell]

So asides from the reason that I posted initially why it is important that the default CSS is put into the CSS Class fields:

If you are going through and finessing your design you are unable to search for

WHERE CSS Class IS UNDEFINED

Whereas you are able to search the BSV for specific strings, such as the default CSS Class for elements within the BSV.

The inability to find the empty CSS Class fields makes it a VERY painful and laborious exercise to make sure you've changed EVERY applicable class.

[hpl123]

-1. This would make changes more difficult IMO. The Kendo CSS change here and there and would be a hassle to update it for Awaresoft and it would also make it kind of decentralized (compared to how CSS is usually managed i.e 1 file that has it all). Currently the way it is set up, you do all of your changes in a custom CSS file OR you create a new theme for your app and you then have full control. Works great I think and we can do more or less anything CSS and style wise and I would not want that to change.

[PointsWell]

-1. This would make changes more difficult IMO. The Kendo CSS change here and there and would be a hassle to update it for Awaresoft and it would also make it kind of decentralized (compared to how CSS is usually managed i.e 1 file that has it all).

I think we may be talking at cross purposes, I'm not suggesting CSS Styles be distributed, just the class names being applied. At the moment all of the Class fields are NULL.

Currently the way it is set up, you do all of your changes in a custom CSS file OR you create a new theme for your app and you then have full control. Works great I think and we can do more or less anything CSS and style wise and I would not want that to change.

At the moment all of the CSS class fields are NULL unless you have defined your CSS class. Which if you have has required you to touch absolutely every attribute - realistically I have found that the Form CSS Class is the one to change as if you change the CSS Class on the BO Attribute directly then this flows through to queries which are unlikely to be formatted the way you'd format a form.

It's unnecessarily labour intensive to find every attribute that you want to format then touch it individually then repeat for the next. It's also highly likely that the first, second and probably more routes through will miss classes.

Maybe I am doing it wrong.

[hpl123]

-1. This would make changes more difficult IMO. The Kendo CSS change here and there and would be a hassle to update it for Awaresoft and it would also make it kind of decentralized (compared to how CSS is usually managed i.e 1 file that has it all).

I think we may be talking at cross purposes, I'm not suggesting CSS Styles be distributed, just the class names being applied. At the moment all of the Class fields are NULL.

Currently the way it is set up, you do all of your changes in a custom CSS file OR you create a new theme for your app and you then have full control. Works great I think and we can do more or less anything CSS and style wise and I would not want that to change.

At the moment all of the CSS class fields are NULL unless you have defined your CSS class. Which if you have has required you to touch absolutely every attribute - realistically I have found that the Form CSS Class is the one to change as if you change the CSS Class on the BO Attribute directly then this flows through to queries which are unlikely to be formatted the way you'd format a form.

It's unnecessarily labour intensive to find every attribute that you want to format then touch it individually then repeat for the next. It's also highly likely that the first, second and probably more routes through will miss classes.

Maybe I am doing it wrong.

I look at it like this. You have the Kendo theme you select in the config tool, that is the "default" and then all of the CSS fields here and there in the config tool is to change the default in a minor way, add minor stuff to the default or do minor overrides. If you need to do changes on a grander scale e.g all forms etc. in a app, you create a custom Kendo theme.

If you need help customizing a theme or doing advanced styling of Aware apps I know a guy wink wink .

[PointsWell]

I would disagree.

If you change a button's CSS class that is trivial only until you have 100 queries with operations on records that have to be touched individually. The number and task expands when you then may have reference attributes within BO forms. The task then balloons again when you have more than one form for a BO.

Building a theme for that is just another layer of complexity.

The challenge is ensuring you've found all the places where that button that you need to change might occur. You can't search for it so it is a manual hunt.

[customaware]

I add a css class to every button in every application I write. This is mainly for the button and icon colour.

My classes are...

addbtn
editbtn
deletebtn

and then..
bluebutton
greenbutton
purplebutton
orangebutton
goldbutton
redbutton

So..... If I change the css for say, the addbtn, then every addbtn in the entire app changes