Hi Om,
the last sample seems good to me and I agree with avoid having the "effect"
attribute in the class and promote composition. So to start, I would remove
the "mdlEffect" attribute from mdl components and instead create a bead
with it, ok?
thanks!
2016-10-24 23:33 GMT+02:00 OmPrakash Muppirala <bigosma...@gmail.com>:
> 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.
> >
>
--
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.
