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
