Development Workflow?

edited January 2012 in Enyo 2
Hi, just exploring, but I'm wondering how real-world apps get built with enyo.

Do enyo developers typically create the UI first in HTML and translate it to enyo code, or do they actually build the UI in javascript? The former seems to violate DRY while the latter seems somewhat tedious and to violate separation of code and layout.

For instance, in the tutorial, a simple div is suggested:

image
handle: tweet text


and then translated to enyo code for the app:
enyo.kind({
  name: "Tweet",
  kind: enyo.Control,
  tag: "div",
  style: "border-style: solid; border-width: 2px; " +
         "padding: 10px; margin: 10px; min-height: 50px",

  published: {
    icon: "",
    handle: "",
    text: ""
  },

  components: [
    { tag: "img", name: "icon",
      style: "width: 50px; height: 50px; float: left; padding-right: 10px" },
    { tag: "b", name: "handle" },
    { tag: "span", name: "text" }
  ],
This is just a trivial example, but I can envision this being a problem in a complicated UI. If I'm already creating the UI in HTML, why should I have to translate every tag to an enyo component? Isn't layout what HTML/CSS is designed for, and shouldn't it be separated from the application code?

Maybe I'm not making myself clear, but coming from the traditional webapp world, I can't really wrap my head around this paradigm.

Thanks.

Comments

  • I used to have the same conflicts when I first started with Enyo (almost a year ago!).

    At first, I also wanted to write HTML and then port to Enyo Kinds. You'll get over it quickly and start thinking of Enyo as HTML. Then it will be second nature. I actually prefer it this way now...
  • edited January 2012
    You're doing separation of code and layout by styling it with CSS. If it helps, you can also have your layout code (more of a scaffolding you later style with CSS) in a separate kind and include the layout as a component in the kind with all the code.
  • edited January 2012
    Yeah, in the tutorial I have a lot of inline styling because I wanted it to be able to be run from the Chrome or Firefox web console. You can have those styles specified in a CSS file and just provide your classes.

    I also didn't separate out a data model into its own class here -- you'd probably want to have a web service sync with a local WebSQL database or HTML LocalStorage, then use that to render the views in a real app.

    A lot of this is easier once you've got some widget sets built up. You also don't need to make each HTML element its own tag, you could also just stuff HTML into the Control using the setContent() method. I could have rewritten Tweet to use a template to format some HTML for the inside instead of writing a hierarchy.

    One other thing -- our widgets, especially lists, tend to follow a format where you don't end up with a lot of Enyo controls instantiated. Instead, the outer container handles keeping just one inner control created, with the others just being DOM elements that may or may not actually be around. We have a whole VirtualList type in webOS that maintains just enough DOM elements to allow for scrolling up or down a page. This avoids needing to pull in all the data at once and store a lot of JS objects in memory for a long list.
  • I agree with James, Enyo was a bit confusing at first, but now it's second nature. I also think that once Enyo 2.0 gets UI components, this will be an easier concept to grasp, as you'll mostly be manipulating those components (or custom versions of those components)
  • Yeah, while lacking the prepackaged UI components, things are probably a bit more than confusing right now. :)

    Hopefully, on the topic of lists, the new List types will have a function call that can query how many elements are actually in the list, and guesstimate it's total size, so that a scrollbar can be easily implemented :)
  • Yes, the current paged setup is sort of a mess for that, and for performance on low-powered environments...
  • Thanks. I guess I just have to get my hands dirty and see how it works out. I'll probably have to mock up HTML at first until I understand how it all works together.

    It's probably just a function of familiarity, but when I see a web page or app, I can easily envision the HTML/CSS, or when I see raw HTML I can envision the resulting UI. But when I see enyo component code, I can't envision anything, so I'm not sure how to translate the web app in my mind's eye into enyo code, other than an intermediate HTML step.
  • That's because of the lack of UI components. Next month you'll see things much clearer
Sign In or Register to comment.