Dealing with multiple view in Enyo 2.2

I'm very new to Enyo and I've essentially immersed myself in Enyo for the last few days, really rather enjoying the experience. The one thing I haven't really been able to get my head around is dealing with multiple views, particularly transitioning and passing data from one view to another.

Also what is considered best proactive when it comes to navigation inside your app, switching from view to view?

Does anyone have a sample app, snippet or a plan of attack? Any help appreciated.

Comments

  • Enyo is primarily designed around single-page apps. One common idea is to use panels to have your multiple views and transition from one panel to another under program control. The Sampler does that, having one panel for choosing a subprogram, and another panel for interacting with the sample.

    In Enyo 2.3, we have a router kind that handles sending events when the URL changes, which can be another way to control the flow of the app. I've seen some apps that have a master view, then use createControl to instantiate a child, and destroy the child and make a new one when that task is finished.
  • I may well hold out for 2.3 then, I'd rather handle it with some kind of routing system. The alternative is is messy.
  • edited June 2013
    A router sounds ideal. Is this going to be implemented as part of Application.js ? I'm looking at Bootplate MVC, and I'm wondering if there's a way to call the Application to create a new view dynamically? This doesn't work, but gives the idea of what I'm trying to do:
    //In a controller....
        forgotPassword: function () {
          console.log("forgotPassword");
          app.view='Bootplate.ForgotPasswordView';
          app.render();
        },
    Uncaught TypeError: Object Bootplate.ForgotPasswordView has no method 'hasNode' 
    I'd like to tell the app that the view has changed, and re-render the new view. Will something like that work?
  • I'm not completely certain but you could try doing app.view = new Bootplate.ForgotPasswordView(); since it's looking for an object to be there.
  • edited June 2013
    Getting warmer, the app.view does get set to an instance of the new view. But the app.render(); doesn't accomplish anything (view remains unchanged).
        forgotPassword: function () {
          console.log("forgotPassword");
          app.view = new Bootplate.ForgotPasswordView();
          app.view.render();
          app.view.show();
          app.render();
          console.log("done");
        },
    
    If I destroy the existing view first, I end up with a blank screen.
        forgotPassword: function () {
          console.log("forgotPassword");
    app.view.destroy();
          app.view = new Bootplate.ForgotPasswordView();
          app.view.render();
          app.view.show();
          app.render();
          console.log("done");
        },
    

  • Hmmm, I'm not sure if this is the intended use of the view property. You might want to construct a new enyo.Application that uses the view you want and make a new instance of that. It SHOULD render its view into document.body and destroy everything else in the process.
  • edited June 2013
    Thanks! Yes, this did it. I created a second app (app2.js) and added to my package.
    enyo.kind({
      name: "Bootplate.Application2",
      kind: "enyo.Application",
      controllers: [ {
        name: "forgotPassword",
        kind: "Bootplate.ForgotPasswordController"
      }],
      view: "Bootplate.ForgotPasswordView"
    });
    And the instantiation:
    forgotPassword: function () {
      console.log("forgotPassword");
      new Bootplate.Application2({name: "app2"}).renderInto(document.body);
      console.log("done");
    }
    Still feels wrong. I hope 2.3 and the routing comes out soon. That sounds like the wiring for the views will be a configuration.
  • edited June 2013
    If you can use enyo.Application, you should already be able to use enyo.Router (check source/kernel for Router.js). Unfortunately, the nightly API tool isn't showing how to use it for some reason, so look at the source for the defaultRoute property and routes array comments
  • The API tool analyzer is a bit broken right now... it doesn't understand the "immediate-invoked function" syntax. That reminds me that I need to unbork it.
Sign In or Register to comment.