5 Replies Latest reply on Feb 9, 2009 11:56 AM by Newsgroup_User

    Event name collisions

    istrasci
      As I'm finally getting the hang of how to use custom events and custom event classes, I realized that there might be naming conflicts... For example, my class defines a custom event

      [Event(name="myEvent", type="flash.events.Event")]

      If I am using one/multiple third-party components in my application, there's no guarantee that they have not also defined an event of the same name & type... If the third-party code includes sizable/long files, I don't want to have to go scraping through to make sure they don't have any of the same names... Or even if my own project has many files, I may have duplicated a name I already used elsewhere... I realize that the chance of the name being the same is small, but with something that follows a convention (like "myEvent"), it could produce a conflict -- more likely within your own project files...

      So how does Flex deal with conflicts??? Compiler warnings/errors??? Do they allow them to go through and force the developer to deal with them? Just wondering...
        • 1. Re: Event name collisions
          ntsiii Level 3
          This is a good question. I typically use long descriptive strings for my events and have not yet really worried about this. But I am about ready to go to the next level.

          I see that the framework, and many other professioonal grade components, use what looks like an "ENUM" of sorts, so instead of "myEvent", you specify the type like MyClass.MYEVENT. I suspect that this make name collisions very unlikely

          I do not yet know how to set this up in a component (haven't looked yet!) maybe someone here can give us a head start.
          • 2. Re: Event name collisions
            istrasci Level 1
            I'm not sure if this is what you're talking about or not... But if I call

            addEventListener(MouseEvent.CLICK, handler1); OR
            addEventListener(ListEvent.CHANGE, handler2)

            MouseEvent.CLICK and ListEvent.CHANGE are just string constants defined in their respective class... So the value of MouseEvent.CLICK is just "click" (in documentation)... This basically just makes it easier to tell the addEventListener what type to listen for, instead of having to remember the exact string that is used... But this doesn't eliminate the problem, because even if you use a string constant, it could have a value that is already "taken"...

            Or did I misunderstand what you were saying...?
            • 3. Re: Event name collisions
              ntsiii Level 3
              You may be correct. Perhaps then this just allows for complex strings as the event names?

              I really do not know.
              • 4. Re: Event name collisions
                Level 7

                "ntsiii" <tspratt@lariatinc.com> wrote in message
                news:gmpols$24l$1@forums.macromedia.com...
                > This is a good question. I typically use long descriptive strings for my
                > events and have not yet really worried about this. But I am about ready
                > to go
                > to the next level.
                >
                > I see that the framework, and many other professioonal grade components,
                > use
                > what looks like an "ENUM" of sorts, so instead of "myEvent", you specify
                > the
                > type like MyClass.MYEVENT. I suspect that this make name collisions very
                > unlikely

                No, it just helps avoid typos.


                • 5. Re: Event name collisions
                  Level 7

                  "istrasci" <webforumsuser@macromedia.com> wrote in message
                  news:gmpn9v$9e$1@forums.macromedia.com...
                  > As I'm finally getting the hang of how to use custom events and custom
                  > event
                  > classes, I realized that there might be naming conflicts... For example,
                  > my
                  > class defines a custom event
                  >
                  > [Event(name="myEvent", type="flash.events.Event")]
                  >
                  > If I am using one/multiple third-party components in my application,
                  > there's
                  > no guarantee that they have not also defined an event of the same name &
                  > type... If the third-party code includes sizable/long files, I don't want
                  > to
                  > have to go scraping through to make sure they don't have any of the same
                  > names... Or even if my own project has many files, I may have duplicated
                  > a
                  > name I already used elsewhere... I realize that the chance of the name
                  > being
                  > the same is small, but with something that follows a convention (like
                  > "myEvent"), it could produce a conflict -- more likely within your own
                  > project
                  > files...
                  >
                  > So how does Flex deal with conflicts??? Compiler warnings??? Do they
                  > allow
                  > them to go through and force the developer to deal with them? Just
                  > wondering...

                  Most of the time it doesn't matter, because you're listening specifically to
                  a component, and you know what events that component is going to send you.
                  In cases where you get a conflict, it's because you're listening for
                  bubbling events, and it's possible that multiple components could be
                  bubbling events with the same name. But then, we already have ways to
                  handle that (think about what you do if you're listening for a click event
                  on a parent container that contains multiple child containers--how do you
                  distinguish if it is the parent or which of the children it is).

                  Sometimes, you could run into a problem if you had, for instance a custom
                  MyClickEvent with a type of "click", because if you type the argument as
                  MyClickEvent and the argument that the listener gets is a normal click
                  event, you will get a runtime error when it tries to cast the MouseEvent to
                  a MyClickEvent on its way into the handler. To handle this, you should just
                  type the argument as Event and then use the "as" keyword to cast to your own
                  event type and handle the vent if your variable that contains the cast event
                  is not null.

                  If you're producing components for "public consumption", you should probably
                  try to give them a long string as Tracy suggested, because the longer the
                  string is, they less likely there are to be collisions. So "clickOnAFoo" is
                  much less likely to cause a conflict than "click".

                  HTH;

                  Amy