PDA

View Full Version : Reset or remove all added css classes (ExtJS 4.2.x)



arnoldvillasanta
19 Dec 2014, 3:27 PM
What's the best way to "reset" or "remove all" user-added css classes without manually tracking what css class/es were previously added?

My usecase is that I have a text field called Sales Order Number, in which text-color of both label and field should change color (red, green, black, orange, blue) depending on the status (new, approved, rejected, pending, on-hold).

My option before was to use setFieldStyle (overwrite same style declarations) for the text field but I guess it's neat to use css class instead (if other styles will be added in the future).

If there is no other convenient way than to use setFieldStyle, then what is the approach to do "setLabelStyle"?

arnoldvillasanta
20 Dec 2014, 1:43 AM
While waiting for the best answer, I'll use replaceCls([cssClass1, cssClass2, cssClass3], cssClassA) for now:


Ext.getCmp('SalesOrderForm').child('#soNo').el.replaceCls(['sj-form-number', 'so-form-number', 'ro-form-number'], 'rvo-form-number');


It's a good thing that replaceCls does not throw error/exception message when the specified css classes are not applied to the component's el.

Anyway, I hope there'll be convenience method soon, like :


replaceCls(replaceAll, cssClassA)

where replaceAll is a boolean tag

This reminds me of how Sencha did a good job in adding 'dirty' tags in the grid panel, that enables a single sync command do all the dirty-works (CRUD) in the backend.

Also, in my opinion, replaceCls() should be wrapped as a convenience code for 'all' components... so that it will be visible within the components' document and code-assist, just like addCls() and removeCls().

I also believe that resetCls() will be more valuable than removeCls()... as it is more convenient for coders to simply reset everything than to track which css classes were added on the fly.

skirtle
20 Dec 2014, 7:19 AM
The idea of resetting/removing user-added CSS classes doesn't really stand up to scrutiny. In your use case you have 1 set of mutually exclusive classes but that's a very specific case. As soon as you have other classes added for other purposes it struggles as a concept. e.g. What if a plugin wanted to add a class, how would the component know not to reset that too?

You need to throw a bit of encapsulation at the problem. Subclass the text field to add a method that tracks the class:


Ext.define(..., {
...

setStatusCls: function(cls) {
var oldCls = this.statusCls;

if (cls === oldCls) {
return;
}

if (oldCls) {
this.removeCls(oldCls);
}

this.statusCls = cls;

if (cls) {
this.addCls(cls);
}

// If the cls could change the component size you'd call updateLayout here
}
});

In this implementation the statusCls is passed in but alternatively it could be the status that is passed in and the setter could be responsible for mapping it to the relevant class.

If you wanted to scale this to many fields in the same form you could consider adding the CSS class to the form instead and using a bit of CSS selector magic to target the fields inside the form.

arnoldvillasanta
20 Dec 2014, 4:17 PM
Thanks Skirtle,

With regards to:

What if a plugin wanted to add a class, how would the component know not to reset that too?


Hope this brings value... (disregard if not):

component.addCls(newCssClass, removable)... an optional boolean parameter to tag the cssClass as removable.
Or maybe a completely different method like component.applyCls(newCssClass) which will indiscriminately remove all cssClasses of the component.
You're right that my use case is very specific. This is also my first time to do a very fancy (eye-catching) user interface that will require a lot of css updates in almost every user event.

With regards to:

You need to throw a bit of encapsulation at the problem. Subclass the text field to add a method that tracks the class:

I'll try this. Thanks.