Carlos,
The thing is that we are loosing our time here. We were discussing
solutions for that in the separate thread - it took as more than 60 emails.
It's starting again. You have something which is working, it's require to
add your custom logic in the component. Building a component end up with
custom logic - in most cases.
Please test your solutions and let us know where you end up. This
discussion is never ending story.
On the users mailing list Alina is having problems with Maven build. She is
trying to port Large application to Royale. It is our huge opportunity to
boost Royale to the next level.
Why not moving forward with current solution - once you get set of your
components ready - Improve things.
I bet you will end up with much more crucial problems than why we are using
custom List to manage className instead of build one. - I'm all for build
one Carlos! But the thing is I have spent three days on doing something
with the build one and end up with Harb's solution.
Thanks, Piotr
2018-03-13 8:38 GMT+01:00 Carlos Rovira <carlosrov...@apache.org>:
> 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
> http://about.me/carlosrovira
>
--
Piotr Zarzycki
Patreon: *https://www.patreon.com/piotrzarzycki
<https://www.patreon.com/piotrzarzycki>*
