Extending VirtualRepeater and the onSetupRow event

edited October 2012 in Enyo 1.0
When I extend VirtualRepeater using
enyo.kind({
name: "Test",
kind: "VirtualRepeater",
onSetupRow: "onSetupRow",

onSetupRow: function(sender, index) {
this.log();
}
});
...onSetupRow is never called.

What's the best way to catch events from the inherited kind?
Kind of annoying that I have to put VirtualRepeater into the components block instead of just extending it.

Comments

  • The problem is that you don't listen for an event and act on it in the kind that raises the event. You would normally include your extended kind in another component and do the mapping of onSetupRow event to a handler in there.
  • You would normally include your extended kind in another component and do the mapping of onSetupRow event to a handler in there.
    Yes, but that doesn't always make sense. E.g. if I have a kind that is supposed to display a list of accounts I'd want to handle the setupRow event inside that kind.

    So, is there another way I could listen to the event (and keep a good code style)?
  • You could probably override the function that calls onsetupitem and instead of firing the event, use this.bubble() and catch the event in the handlers block of ur new kind
  • Looking at Repeater, there are 2 methods that can fire the doSetupItem() call, so you'd need to override both of them.

    However, I'm wondering if you could just override doSetupItem on your extended Repeater, do your special processing, then call this.inherited(arguments) at the end?

    Never tried it, but it might work.
  • As Dave says, the simplest way to do this is just to include your VirtualRepeater inside another component (call it AccountsList, for this example), and handle onSetupItem in that kind.

    You'd also presumably provide some methods and/or properties on the AccountsList, so you can re-use it in multiple places. Have a property that holds the list of accounts to display, or whatever.

    This is more or less how the Accounts list in the WebOS email app worked, though it wasn't as nicely factored as I would have liked.

    In general, Enyo favors composition of components, rather than subclassing, as the preferred mechanism for implementing your application logic. You really only need to subclass a kind when you want to change it's behavior in a significant way, or in a way that involves seeing and changing the internal state.
Sign In or Register to comment.