Thinking about this more, we could enclose components in a container div.
The component would have the frozen styles and any classnames the user sets
would would be on the parent div. This way, due to the cascading nature of
CSS, the component would get the appropriate styles while maintaining the
frozen styles.
For example, in FontAwesome, the current implementation is:
<fa:FontAwesomeIcon iconType="fa-twitter">
becomes
<i class="fa fa-twitter">character_code</i>
If user sets a classname property in mxml:
<fa:FontAwesomeIcon iconType="fa-twitter" className="myColor">
becomes
<i class="myColor">character_code</i>
unless we do a lot of internal class name maintenance.
Instead, if we have the implementation as:
<div>
<i class="fa fa-twitter">character_code</i>
</div>
Setting a class name could be done this way:
<div class="myColor">
<i class="fa fa-twitter">character_code</i>
</div>
The <i> element would still inherit the myColor class and the component
will not get modified externally.
The only drawback is an additional <div> but I think that is acceptable.
Thoughts?
Thanks,
Om
On Jan 14, 2017 7:54 AM, "Carlos Rovira" <carlos.rov...@codeoscopic.com>
wrote:
> Hi Om, Alex,
>
> thanks for the suggestions but that not work. After sleep and thin about it
> a little more my understanding is that this is really not a problem of
> malfunctioning, is simply that we have properties that operates visual
> changes based on CSS, so the right way is yo apply the instruction *per
> property*, since is in that case where we need the property to be part of
> the frozen styles (if toggles to stay or is removed). In the rest of cases
> this not apply and other kind of use by the customer should allow him to
> override all if he want...if not he should make the same as we do to let
> class selector remain.
>
> It's a bit of work, since I must to go through all the components making
> this change in all the properties that behaves similar, but...don't see
> other quick way where we could change in one point and affect all in the
> right way.
>
> Thanks!
>
>
> 2017-01-14 7:10 GMT+01:00 Alex Harui <aha...@adobe.com>:
>
> > typeNames are classSelectors meant to act like TypeSelectors. Like
> > DataGrid or DropDownList. If the customer sets className it shouldn't
> > affect typeNames.
> >
> > Can the customer also use the classList API? If so, then you may need
> yet
> > another thing like typeNames like "internalClassNames" which is the list
> > controlled by the component developer and different from the classNames
> > specified by the customer.
> >
> > Or maybe the way you are currently using classNames inside MDL should
> > actually be changing typeNames.
> >
> > My 2 cents,
> > -Alex
> >
> > On 1/13/17, 6:44 PM, "omup...@gmail.com on behalf of OmPrakash
> Muppirala"
> > <omup...@gmail.com on behalf of bigosma...@gmail.com> wrote:
> >
> > >On Jan 13, 2017 6:30 PM, "Carlos Rovira" <carlosrov...@apache.org>
> wrote:
> > >
> > >Hi,
> > >
> > >found an issue with MDL and custom class.
> > >
> > >If you declare a component that has some new custom additional class
> (lets
> > >call "someClass"), and has some property that modifies the className (in
> > >our case always through classList API), let's say is a button, and this
> is
> > >the example:
> > >
> > ><mdl:Button colored="true" className="someClass"/>
> > >
> > >the result is the colored className is remove from the list of applied
> > >classes, since is not part of "typeNames" and className implementation
> > >overrides all
> > >
> > >We must say that properties that modifies className in MDL like
> "ripple",
> > >"colored", etc... are by definition "behaviors" that use CSS
> (classNames)
> > >to modify some visual aspect of the component or control, so me want
> don't
> > >be affected if we apply a custom className like "someClass" right?
> > >
> > >So If we set "colored" to true, we want the component maintains the
> > >className that is applied and if we set to false we want to be remove
> from
> > >classNames, and in no other way,
> > >
> > >so the solution I have is to add a line in *each* property of each
> > >component in MDL just behind the classList.add or classList.toggle
> > >instruction that should be:
> > >
> > >typeNames = element.className;
> > >
> > >So, in this way we make the property part of typeNames while is
> activated
> > >and if removed, we remove as well from typeNames, giving the control of
> > >that visual aspect only to the setter of the property
> > >
> > >I'll make that change tomorrow (it's very late here), if no body finds
> any
> > >problem.
> > >
> > >After much testing I don't see other way
> > >
> > >Thanks
> > >
> > >
> > >I ran into a similar problem with FontAwesome. I think this is a good
> way
> > >to fix this.
> > >
> > >Can we override the classname setter to do
> > >
> > >typeNames = element.className;
> > >
> > > after calling super?
> > >
> > >Then maybe we dont need to do this in the future?
> > >
> > >Thanks,
> > >Om
> > >
> > >
> > >
> > >--
> > >Carlos Rovira
> > >http://about.me/carlosrovira
> >
> >
>
>
> --
>
> Carlos Rovira
> Director General
> M: +34 607 22 60 05
> http://www.codeoscopic.com
> http://www.avant2.es
>
> Este mensaje se dirige exclusivamente a su destinatario y puede contener
> información privilegiada o confidencial. Si ha recibido este mensaje por
> error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
> proceda a su destrucción.
>
> De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos
> que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
> S.A. La finalidad de dicho tratamiento es facilitar la prestación del
> servicio o información solicitados, teniendo usted derecho de acceso,
> rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras
> oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
> necesaria.
>
