André and I were just discussing this, although in the context of the LFC. I've cc-ed him, so he can correct me if I misstate things.
For components: If you do _not_ write a setter, you don't need to declare an event. If you _do_ write a setter, you will want to declare the event, so your setter can test and send the event without having to first test that the event has been created. The runtime _will_ create an event for anything you try to listen to. This is one of the reasons user classes have to be dynamic. (André's solution to make events more DOM-like will move events into their own object, solving that issue.) That's a pretty strong feature of the language, although it results in you getting no warning if you try to listen to an event that no one will ever send. E.g., you can write: <handler name="onmooseout"> ... </handler> and wonder why it does not ever get called. You only have to declare an event in user code if you are creating a "naked" event, one not associated with an attribute, but that is an idiom we try to discourage. For documentation purposes, we recommend that events that have a corresponding attribute be marked 'private' because they are assumed to exists, so just clutter the documentation. In the LFC, you must declare the @lzxtype event of any private events for them to get into the schema (which makes them settable in the open tag). On 2011-01-24, at 14:43, Henry Minsky wrote: > If I declare an attribute, e.g., > > > <attribute name="duration" type="number" value="0"/> > > Is an "onduration" event implicitly declared for it by the compiler? > > I'm trying to implement a component which has an "onduration" event as part > of it's API, and wondering > if I should declare the event explicitly or not. > > > -- > Henry Minsky > Software Architect > [email protected]
