OK, I do have a setter on most of these, so I'll declare an event for them.
On Mon, Jan 24, 2011 at 3:12 PM, P T Withington <[email protected]>wrote: > 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] > > -- Henry Minsky Software Architect [email protected]
