I think the key point to look at is that we want favor composition over
inheritance.
In our case,
Inheritance:
<mdl:Button effect="effect1 effect2 effect3"/>
This dictates that mdl:Button should implement an 'effect' setter/getter
and code for handling the each of the values, regardless of whether we want
an 'effect' in our button or not.
Composition:
<mdl:Button>
<mdl:Beads>
<mdl:effect1>
<mdl:effect2>
<mdl:effect3>
</mdl:Beads>
</mdl:Button>
In this approach, we can choose to add effects to the built-in Beads
property and each effect will carry the code of implementing what it does
to the Button class.
The argument is that this approach is better because we can avoid code
bloat.
A happy medium would be something like this:
<mdl:Button>
<mdl:Beads>
<mdl:effects values="effect1 effect2 effect3">
</mdl:Beads>
</mdl:Button>
This way, we still keep code for 'effects' out of Button. And it is
cleaner to read than the other way.
Thanks,
Om
On Mon, Oct 24, 2016 at 2:16 PM, Carlos Rovira <
carlos.rov...@codeoscopic.com> wrote:
> I love beads, but in this case I think it would be very verbose don't you
> think?
>
> for example in Button:
>
> All has the same two selectors : mdl-button mdl-js-button (in my
> implementation this goes always)
>
> Then we have 8 optional selectors that could be combined in many ways.
>
> So for me de default button is the one with two selectors, then people will
> use normal a combinations of 1 to 3 of the 8.
>
> So instead of
>
> <mdl:Button>
> <mdl:Beads>
> <mdl:effect1>
> <mdl:effect2>
> <mdl:effect3>
> </mdl:Beads>
> </mdl:Button>
>
> Taking into account that this is only a class selector assign...
>
> I will prefer:
>
> <mdl:Button effect="effect1 effect2 effect3"/>
>
> I think beads would be great to encapsulate more complex optional
> code,...but in this case, don't you think is very bloated for this
> particular case?
>
> If finaly you all think beads is better, we would go that way...but for me
> at least, seems not the right way.
>
> Thanks
>
> just my 2...
>
> C.
>
>
>
>
>
> 2016-10-24 22:09 GMT+02:00 OmPrakash Muppirala <bigosma...@gmail.com>:
>
> > +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.
> > >
> >
>
>
>
> --
>
> 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.
>
