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?
2016-10-24 17:21 GMT+02:00 Alex Harui <aha...@adobe.com>:
>
>
> On 10/24/16, 2:42 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
> <carlos.rov...@gmail.com on behalf of carlosrov...@apache.org> wrote:
>
> >> Here's another idea idea: what if there was a compiler option that
> >>would
> >> override the xmlns in the MXML files?
> >>
> >> mxmlc -compiler.mxml.xmlns=js,library://ns.apache.org/flexjs/mdl
> >>
> >>
> >That would be ok, but it seems a bit tacky to me...my vote would be not
> >introduce things like this and keep it as clean as possible.
> >
> >
> >
> >>
> >> Just so I'm clear, is your concern that you don't like setting the
> >> className property in ActionScript? But isn't that essentially how you
> >> would do it in HTML? IOW, you would open an HTML editor and write:
> >>
> >> <html>
> >> <body>
> >> <button class="mdl-button" />
> >>
> >> IMO, what we are doing in writing AS components is taking common
> >>patterns
> >> from HTML and reproducing them in AS. So I'm not really sure it is
> >>wrong
> >> to be setting className="mdl-button" in the Button.as for the MDL.swc.
> >>
> >
> >What I don't really one is to end declaring a "height" or "color" or
> >"className" in component code. I feel it like is very bad. don't you?.
>
> I don't think setting className is bad if it is what you normally do when
> hand-coding HTML. Setting height in code would probably be bad. Setting
> height in a defaults.css may be ok if that is the default you want for
> that component set.
>
>
> >I do it in order to continue progressing, but don't like it as final since
> >this shouldn't be applied in the component.
> >If I have a MDL component set...is clear that I should use "mdl-button"
> >(in
> >a button), but there's some optional params to get different mdl buttons
> >(fab, raised, with ripple...i.e: mdl-button--fab) so maybe in the MDL
> >Button it could be a tag attribute like "mdlEffect", that could set as
> >"fabAndRipple" or "raised"... (but in my actual implementation, that I
> >don't think it should be final).
> >
> >Thinking about what I would like to have: if we want to end with js:Button
> >getting a MDL style and effect, that's not the way. First, we must make
> >possible to clean all styles inside component code (Core.js or HTML.swc
> >should not have any style config in code), and then apply it as external
> >CSS. If I want to change default for mdl style, I think we could introduce
> >something new like:
> >
> >js|Button {
> > className: mdl-button mdl-js-button mdl-button--fab mdl-button--colored;
> >
> >}
> >
> >(maybe thinking loud)
> >
> >...or something similar. This would allow great flexibility without mixing
> >control and styling.
> >
> >Of course, in addition I should need to change DOM composition overriding
> >the Button's createElement method (...and maybe this could be done as well
> >vía config ?...but maybe to think at later time ;))
> >
> >what do you think?
>
> IMO, being able to change the DOM subtree based on CSS is not a good idea
> unless the browsers can do it for you. Otherwise, there will be if/then
> statements in our code examining the CSS and determining what elements to
> create. That is not pay-as-you-go. As a code minimalist, if/then
> statements are a bad thing if you don't need to change something at
> runtime. Assuming many folks pick their theme at compile time, the tool
> chain should select the right code tuned for that theme. That's why I
> want to pair a SWC with components with different createElement subtrees
> with the defaults.css that goes with it.
>
> IMO, the fact that CSS has "class" selectors means that they intended for
> the "class" property to define new classes for the CSS Engine. So, IMO,
> each unique set of class selectors should map to a true ActionScript class
> in FlexJS. So, not only would you have a Button class, but also a
> RaisedButton, FabButton, and even a FabAndRaisedButton. That way the API
> documentation better identifies the common patterns available.
>
> If there are other class selector options that are more like attributes or
> flavors instead of classes, or you think the number of combinations would
> be overwhelming, you could also define beads and have the FabBead append
> the mdl-button--fab to the className list.
>
> If you have a "base" set of selectors that all Buttons must have, you can
> override the className setter to make sure those selectors are
> automatically added to the list. There is also a "typeNames" property
> that appends certain selectors to the list of classNames. If we need to
> have some prepended, we could add that as well.
>
> Of course, anyone is welcome to build out a component set that does take
> the time to switch the dom tree at runtime, but the basic component set
> probably shouldn't do that, and the tool chain is going to learn how to
> package styles with code in a SWC and have replacement of SWCs replace the
> defaults.css as well. It occurred to me this morning that I don't really
> know why the Button selector keeps ending up in the output in the first
> place. I will look at that at some point.
>
> -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.
