More newbie questions: menus, events, code organization

Hi! Thanks to the help of Ryan and Ben, I'm making progress on my learn-Enyo to-do app:

http://jsfiddle.net/N9L4z/

I just added deleting items via a pop-up menu, and I have a few questions:
  1. The popup menu appears at the bottom of the whole list, rather than near the item that's triggering the event. To get around that I could attach a menu to each list item, but that seems crazy. What's the right way?
  2. On mobile when holding down on an item to get the menu, the keyboard pops up because the item has been selected. I could try deselecting the text field when the popup happens, or I could try intercepting whatever event is causing the text field to focus and focusing later if the menu isn't up. Debugging the event flow, there are zillion events going on. What's the right approach, and which are the right events to intercept?
  3. With this code, I'm starting to feel a desire for better organization. If I keep going, there's going to be too much in the ToDoList, and it seems like there's a lot of things getting into the business of other things. (E.g., popup menu holding the index of the selected item, various methods manipulating the backing data.) Are there good resources or examples on organizing Enyo code for maximum clarity and maintainability?
Thanks!

Comments

  • 1. I made some changes at jsfiddle.net/warpuser/N9L4z/1/. Basically, I'm using a popup instead of a menudecorator/menu.

    2. See http://forums.enyojs.com/discussion/comment/8841/#Comment_8841

    3. A tough one and something I'm struggling with as well. Hopefully, someone more masterful can answer this one...
  • Thanks, psarin! That's helpful. The pop-up doesn't look as menu-y as the menu did, but it does pop up in the right place. I'll run with that for now.

    Do you have opinions on when to create new components dynamically versus creating them at the start versus hiding/showing them? It occurs to me that menu items here will eventually have to change to be contextually correct. In other contexts that means I'd just make the menu on the fly when I get the hold event. But I'm wondering if that's the right behavior in Enyo-land.
  • Regarding item 2, the handling of events around a popup on an Input: I'm afraid I'm still struggling.

    It looks like the HTML Input (as opposed to enyo.Input) is doing the focusing. To prevent doing a focus during the long press that gets the popup, I'm hooking into onDown and doing preventDefault on the event. So far, so good; the menu appears and the input doesn't focus.

    Then I add an ontap handler that throws focus to input if the menu isn't up. Which sort of works, but instead of just putting the edit point at the tap point, it selects the whole field. There is an API that lets me set the selection, but it does it in terms of character positions, not x and y, so I don't see how to usefully simulate a tap on an Input if they aren't doing a hold.

    Normally I'd just look at the source code for Input and hook in or duplicate logic. But since that's not part of Enyo, that doesn't seem fruitful. This is weird enough that I wonder if I'm Doing It Wrong. Would it be better to treat it as normal text content and then swap in a focused Input on tap? But that still leaves me with the problem of finding the right focus point. Is there some other Enyo control that I should be using instead? Nothing is obvious, but then I'm a newbie, so maybe I'm just missing it.

    Any opinions welcome!
  • Probably best to make / destroy them dynamically. That way you don't have too many components lying around in DOM, taking up memory.

    You could style the popup to look more like you want it.

Sign In or Register to comment.