Thanks Alex, I think I'll stick with the actual impl for the moment, maybe flags could be good...Others don't like since I think are or very verbose or many combinations...
btw, I was trying to get -compiler.exclude-defaults-css-files=HTML.swc:defaults.css without luck, but is clear this is a must, since If I add DataGrid, or whatever, it brings all selectors I don0t want. So hope you get why is not working. in the mean while, I'll try to continue my way trying to skip those styles if I can. 2016-10-24 18:40 GMT+02:00 Alex Harui <aha...@adobe.com>: > > > On 10/24/16, 9:17 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira" > <carlos.rov...@gmail.com on behalf of carlos.rov...@codeoscopic.com> > wrote: > > >Ok, I see, > > > >right now I'm using something like you say: > > > >while the base class selectors are asigned in AS3 MDL Button Code > >component: > > > >element.className = 'mdl-button mdl-js-button'; > > > >In example's use I specialize, since there is 8 selectors, and seems to me > >many combinations to make classes, So: > > > ><!-- Fab button --> > > <mdl:Button mdlEffect="mdl-button--fab > >mdl-button--colored"> > > <i class="material-icons">add</i> > > </mdl:Button> > > > > <!-- Fab with Ripple --> > > <mdl:Button mdlEffect="mdl-button--fab > >mdl-js-ripple-effect"> > > <i class="material-icons md-48">face</i> > > </mdl:Button> > > > >So you think this is the best we could get to simplify? > > > > It is sort of up to you. This is a good example about how MXML affects > pay-as-you-go code and usability. > > Like I said, you really could have 8 different buttons. Then the MXML > would be really easy to read: > > <mdl:FabButton /> > <mdl:FabAndRippleButton /> > > But it looks like you would rather create a new property called mdlEffect > and assign some classNames there. And that's fine, but then you were > tempted to add comments about what each button was going to look like, and > the MXML wasn't as easy to read. Folks would have to remember the names > of the MDL selectors, and not mis-type them. > > So you could even create other boolean properties like "ripple" and "fab" > that under the covers would assign the classNames. Then the MXML would > look like: > > <mdl:Button fab="true" /> > <mdl:Button fab="true" ripple="true" /> > > Easier to read as well, but then you've baked in what fab and ripple does > and if some new version of MDL has some new 'effect' like 'awesome', you > have to update your component set to add a new property. Folks can still > use the className property and you have to document the order in which > these properties and className will end up as the actually className in > HTML DOM, and that may not be as flexible as just having everyone put the > list in the order they want. However, they can always fall back to using > none of the options and just setting className in the order they want. > > You could also create beads for each of the flavors. Then the MXML > becomes more verbose: > > <mdl:Button> > <mdl:beads> > <mdl:FabStyles /> > </mdl:beads> > </mdl:Button/> > <mdl:Button> > <mdl:beads> > <mdl:FabStyles /> > <mdl:RippleStyles /> > </mdl:beads> > </mdl:Button/> > > But then you can just release an "AwesomeStyle" bead later. > > I don't think there is a "right" answer. You can even offer all of the > above. This another reason why FlexJS doesn't try to settle on one > default component set. There can be multiple different implementations of > MDL components and folks will figure out for themselves which ones they > like to work with. > > > -Alex > > -- 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.
