+1 for implementing it based on beads.

mdl:DefaultMDLButton would look like this:
<mdl:Button>
    <mdl:Beads>
        <mdl:InkRipple>
        <mdl:FAB>
    </mdl:Beads>
</mdl:Button>

We could simply use DefaultMDLButton in our code instead of having to write
out all the beads, if the user so chooses.

Thanks,
Om


On Mon, Oct 24, 2016 at 12:10 PM, Josh Tynjala <joshtynj...@gmail.com>
wrote:

> I like Alex's suggestion of making beads for each variation you can add
> (fab, ripple, etc.). Feels like the FlexJS way to do it.
>
> - Josh
>
> On Oct 24, 2016 11:18 AM, "Carlos Rovira" <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?
>
>
>
>
> 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.
>

Reply via email to