Hi Alex, I think you already did a good job maintaining making think PAYG and avoiding "just-in-case" cases. Things are under control right now. Users should now be happy on that concrete Royale feature. So what I'm saying is that we can focus on "end users value" since PAYG is already very good, even in Jewel.
What I'm afraid is that making PAYG reach new quotes of perfection is not good for Royale now. Since we're loosing focus on getting that "end user value" If we ask users, that mostly does not participate, they will want us to get 1.0 ASAP, more documentation, get better look and feel for emulation (we don't have anyone here that can make this happen for now), or get Jewel DataGrid working completely and usable. And probably they will want event system will always be one way, and not make it depend on PAYG things, since will be more difficult for them to use. IMHO, we have a good balance right now. And Platform things should be always the same. Moreover if it comes from AS3 and Flash that are part of the base of technology people coming from that world expect to have out of the box. Today the problem is not about download bits, we already got a very low foot pint thanks to your focus on that part (and for me is enough), our problem is now in other places like ease of development, or make people that are not working all days since years with Royale in lower the knowledge the need to use the huge amount of beads we already have and that they don't know we have. As the Gall's law says we should evolve from what we have now. Maybe when we have all that problems solved and have 1.0, we can continue iterating things even better with more time, and people will be glad at this time. In exchange, I think if continue refining the already good solution, we can fail to make Royale ready for users and loose all this years. IMHO, instead of writing long emails, we all should be writing more docs to make people know Royale better and succeed doing at least some simple migration or app. Just my 2 Carlos El jue., 26 dic. 2019 a las 3:30, Alex Harui (<[email protected]>) escribió: > > > On 12/25/19, 10:10 AM, "Carlos Rovira" <[email protected]> wrote: > > Hi, > > my opinion is that platform, language and other "core platform things" > (to > call in someway to things that are part of the barebones of the > technology) > should not be as exigent with PAYG as the rest of parts in the > platform. > Events should work always the same, and support always the same things > to > avoid users working with Royale succeed because they understand the > base or > minimal tools to work with. > > Basic is intended to be PAYG. Other component sets do not need to be. > For sure, MXRoyale and SparkRoyale are not. > It doesn't matter what the platform supports. What matters is how much > code you need to do what you need to do. The platform is already > downloaded. The application and framework are not. We don't control > platform startup time. We control application and framework startup time. > Basic should not have a base class that has an API for every browser > feature. If you want Jewel to have that, feel free. > > In the other hand, FWIU that Harbs explained, all things we are > supporting > now that bubbling was already in the google implementation and we're > now > just exposing it (let me know if I'm wrong). So in this concrete topic, > seems not logic to cut functionality or code that is already there. > > When we start adding code to the framework just-in-case, then that is not > PAYG. Bubbling non-interaction events is a bad practice. Basic should > make people pay for using that bad practice. > > Finally, I think some times we are very focused in things that are not > helping us to reach more user or audience. I understand the importance > to > get a very good architecture and code and I think at the time of > writing this we really got a really good code. But I think we're > failing in > reaching people in terms of "what end user value". If we ask a final > user, > they probably will not understand many of the things here, but he'll > try to > do some simple thing and maybe could find that he still can't do > something > or the results does not look as he expect for a modern web app. In that > way, my perception is that we have bigger fish to fry, so hope this to > be > seen as a constructive criticism :). > > See past discussion on the "last mile". I do not want to repeat the > mistakes of Flex. Hopefully most of our users will not need to care about > beads and PAYG, but the ones who do will be glad we did it. The other > component sets are being built to hide beads and PAYG from the final users. > > I've been fixing bugs on our issues list as fast as I can. I haven't seen > a lot of fixes from others but I know other committers have more limited > time and resources. I assume that anything Royale is missing in terms of > "end user value" is being filed as an issue. If not, others should speak > up and open an issue. If there is some simple thing that isn't working, it > needs to be opened as an issue. That's all I can do at this point. I > can't guess what people need. If you think there are bigger fish to fry, > then start a discuss topic on it or open an issue. I'm working on the > biggest things I know of, but I'm also not going to throw out 7 years of > best practices on PAYG and repeat what happened with Flex. Your apps may > not have run into a last mile problem, but my job was all about trying to > help those that did, and we could not help them because we did not have > enough encapsulation in Flex. > > > El mié., 25 dic. 2019 a las 18:06, Harbs (<[email protected]>) > escribió: > > > > IMO, the tree structure of non-HTMLElements should not be required > to > > support a property named “parent" > > > > It’s not. getParentEventTarget (which originates in EventTarget) can > be > > overridden to return anything. > > > > > My point is that the current implementation is not PAYG. > > > > You might make an argument that EventTarget is not PAYG (and it very > well > > might not be), but right now, EventDispatcher extends EventTarget and > > events are currently not working as they should be. > > > > I would argue that we should get rid of EventTarget completely and > create > > SimpleEventDispatcher which has the simplest event architecture and > we > > could use that in many of the places we’re currently using events. > > > > Another option would be to inject all the bubbling code via beads. > There > > might be more options to make it more PAYG. > > Yes, a bead, or have non-interaction events that bubble bring in the code > to support bubbling. The interaction events should bubble because they > dispatch off the element. > > > > > > But until we restructure events, I think they should at least work as > > advertised… ;-) > > Yes, when they are actually used, not "just-in-case". > > -Alex > > -- Carlos Rovira http://about.me/carlosrovira
