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
