Hi Carlos,
I've been so busy trying to get a release out and Alina up and running
that I really haven't tried to understand why our current code is
insufficient for your needs. Please explain it again or else maybe I will
discover it as I try to fix your other problems.
If you want to spend more time improving your solution, go ahead and post
the proposals in your branch so we can see the code. I can't guarantee
that there isn't some solution that uses classList that will be better,
but realize that I've been told that Arrays are much slower than Strings
at times, as are any API calls with a variable number of parameters. So
less code may not perform as well.
The fundamental problem is that an array can be modified (add, remove,
toggle?), but must retain a set of items (the typenames).
Also realize in JS you can cheat and replace a method if you really have
to have some functionality that you can't do some other way. Making
method bodies pluggable adds an extra layer of function calling so we
don't normally do that. But first, you have to code up a working solution
so we can see what can be shared and what needs to be abstracted.
I am so sad and frustrated that we have spent so much time on managing a
set of strings. I just don't think we have the people power to continue
to seek perfection until it is truly needed by a user.
My 2 cents,
-Alex
On 3/13/18, 12:38 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
<carlos.rov...@gmail.com on behalf of carlosrov...@apache.org> wrote:
>Hi Alex,
>
>ok, I saw the problems of using a list as I was creating it for that
>reason
>I try to do this as easy.
>
>to solve that we can introduce a few lines more that handles strings.
>This
>will be less code that current solution and handle both possibilities is
>done in more parts of the framework so I think is still PAYG
>(we change two vars for one var that handle an incoming string or a list
>item, less API han more clear vs a "if-else" processing)
>
>If this is not ok, maybe we could explore a pluggable way for this? I
>mean,
>we all find this is problematic and we're fighting with this long time
>since I found it in MDL. Actual solutions continues to be a problem since
>or make us (library developers) to introduce su much redundant code (MDL
>and Jewel has 2 functions per class to handle this what for me is not
>something fine, since this is a framework thing ). and affects to how html
>output is created (that is important to me).
>
>So why not do this as a pluggable solutions the same way we have
>CSSValuenImpl or others out there and I can put a bead at app level that
>handles this in a particular way?
>(SimpleClassNameManagement and ClassListClassNameManagement or the way we
>want to name it)
>
>What seems to be clear is that :
>
>1.- this part is conflictive
>2.- in the actual way it makes sub libraries to add lots of functions per
>component to manage the actual scenario with classes
>3.- we're divided on how to solve this, but we don't need to take one
>solution over another since for that reason we are creating a very modular
>framework, but in this part is not modular
>
>Thoughts?
>
>Carlos
>
>
>2018-03-13 5:48 GMT+01:00 Alex Harui <aha...@adobe.com.invalid>:
>
>> Hi Carlos,
>>
>> classList was not used earlier because Arrays are cumbersome in MXML.
>>
>> In MXML, folks can add more than one class using space delimited list of
>> strings:
>>
>> <js:Label id="myLabel" className="BigFont SuperScript" label="some Big
>> SuperScript" />
>>
>> In AS, folks can delete classnames via:
>>
>> myLabel.className="SmallFont";
>>
>> I don't believe your proposal takes these scenarios into account.
>>
>> Thanks,
>> -Alex
>>
>> On 3/12/18, 4:04 PM, "carlos.rov...@gmail.com on behalf of Carlos
>>Rovira"
>> <carlos.rov...@gmail.com on behalf of carlosrov...@apache.org> wrote:
>>
>> >Hi,
>> >
>> >I made a branch from jewel branch to try UIBase for you to check
>> >(feature/uibase-classlist).
>> >
>> >My thinking is that classList simplifies all a lot since is a managed
>>list
>> >with steroids that is made for you to use.
>> >I suppose that when FlexJS was started this API was not known or known
>>but
>> >can't be used due to IE limittations.
>> >
>> >To make the experiment I copied UIBase to Jewel library *as is* and
>>make
>> >the changes.
>> >
>> >For me the change is as simple as this:
>> >
>> >private var _className:String;
>> >
>> >/**
>> >* The classname. Often used for CSS
>> >* class selector lookups.
>> >*
>> >* @langversion 3.0
>> >* @playerversion Flash 10.2
>> >* @playerversion AIR 2.6
>> >* @productversion Royale 0.0
>> >*/
>> >public function get className():String
>> > {
>> > return _className;
>> > }
>> >
>> >/**
>> >* @private
>> >*/
>> >public function set className(value:String):void
>> >{
>> >if (_className !== value)
>> >{
>> >_className = value;
>> >
>> >COMPILE::JS
>> >{
>> >setClassName(_className);
>> >}
>> >dispatchEvent(new Event("classNameChanged"));
>> >}
>> >}
>> >
>> >COMPILE::JS
>> >protected function setClassName(value:String):void
>> >{
>> >element.classList.add(value);
>> >}
>> >
>> >this is a first iteration, maybe things can be do better, even simpler.
>> >no more tricky complex things with typenames and classnames
>> >
>> >
>> >you simply add to classlist, or if want to remove call directly
>> >"element.classList.remove", or toggle, or contains.
>> >
>> >I have it working my example in that branch and code simplifies
>>greatly.
>> >
>> >(only buttons, since the rest of controls are still without changes)
>> >
>> >this even made what Alex want with "typeNames" since, If I added a
>>class
>> >"Button", when I extend, it remains without do nothing
>> >
>> >to add "primary" or remove, I only need one line of code:
>> >
>> >element.classList.toggle("primary", value);
>> >
>> >So, what do you think? I know this can be a huge change in Royale, but
>>is
>> >something cumbersome in the actual state, or I had to fight with it in
>> >MDL,
>> >now Harbs, Piotr and all people going that is having trouble and
>>wasting
>> >time.
>> >
>> >Maybe it could be better to just make this change and make Royale more
>> >easy
>> >to change styles without not much hassle.
>> >
>> >All I see are benefits:
>> >
>> >* API is in the browser build-in, so I think it will be performant
>> >* removes lots of inefficient code that is cumbersome
>> >* makes API more easy
>> >* removes the need to have typeNames and classNames since we have
>> >persistent class just out-of-the-box
>> >* we get all the api without the need to add it
>> >(add/remove/contains/toggle)
>> >* it's supported in all browsers we target
>> >* is totaly PAYG
>> >
>> >Please, let me know what do you think. I'll read it tomorrow since I'm
>> >closing for today
>> >
>> >Thanks
>> >
>> >
>> >--
>> >Carlos Rovira
>> >https://na01.safelinks.protection.outlook.com/?url=
>> http%3A%2F%2Fabout.me%2
>> >Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%
>> 7C3c0a0cd0210e45ecbae208d5
>> >886dacbc%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>> 7C636564926990512873&s
>> >data=4sznARhAbaYEIF60rTmfSOsj9gSU1BZhYE18cUgIELU%3D&reserved=0
>>
>>
>
>
>--
>Carlos Rovira
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2
>Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb22c62e751d045fe210a08d5
>88b57698%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636565235344247471&s
>data=UAoZqgaFjtrgjkl8m2pDPoLtmn%2Bx7qtnreDFPREyW3A%3D&reserved=0
