0

Reusing HTMLFrameMojit with another view

Hi, I like mojito more and more!

I want to add some default chrome/ui common (footer, header, ...) to my whole app.

I was thinking about 2 of doing it. 1) in the child of the HTMLFrameMojit (I have some routing problem with that, will talk about it later). 2) in the view of a new customized HTMLFrameMojit .

I'll develop about the 2nd possibilty. I created a new mojit. In its controller i require the HTMLFrameMojit (and its dependencies) and simply do

 
YUI.add('body', function(Y, NAME) { 

Y.namespace('mojito.controllers')[NAME] = Y.Object(Y.mojito.controllers.HTMLFrameMojit);  

}, '0.0.1',
 {requires: ['mojito', 'mojito-util', 'mojito-assets-addon', 'mojito-deploy-addon'
, 'mojito-config-addon', 'mojito-composite-addon', 'HTMLFrameMojit']}); 

Then I copy the HTMLFrameMojit views and customize them as I want.

Few questions about that:

1) Is it bad?

2) Is there a better way of doing it?

3) Of course it is not (totally) working. My mojits are not deploy to the client ( "deploy":true in application.json). Any idea why?

Thanks a lot!

by
9 Replies
  • 3) I answer to myself. It works when I do not forget the {{{remove}}} in the customized view. This makes me think it is not the best way ! :) No?

    0
  • @Dodo, we encourage people to customize their own FrameMojit, so they can have full control of the page initialization, and structure. Here is the doc with the details on how to do that:

    http://developer.yahoo.com/cocktails/mojito/docs/topics/mojito_frame_mojits.html#creating-custom-frame-mojits

    Now, if you're not up for it, you can still achieve the header/footer implementation by creating a container mojit, set up a "base" instance of that which is responsible for setting the header, footer and body children, and later on, you can reuse and customize that per route to load a different content mojit within container, something like this:

    [ { "settings": ["master"], "appPort": "8666", "specs": { "container": { "type": "ContainerMojit", // this one just do `ac.composite.done()` call, nothing else. "config": { "children": { "header": { "type": "HeaderMojit" }, "body": { "type": "DefaultBodyMojit" }, "footer": { "type": "FooterMojit" } } }, }, "custom-page": { "type": "HTMLFrameMojit", "config": { "child": { "type": "container", "config": { "children": { "body": { "type": "CustomBodyMojit" // this overrule the type from the "base" container instance } } } } } } } } ]

    0
  • Thanks a lot for your answer. I missed that part. I like the idea of customizing my own FrameMojit, I will give it a try :-)

    I found no mention of the "__call" method in the doc, about FrameMojit.

    But it looks necessary to use it (in the FrameMojit), in order to have a default action.

    Is it safe (or internal api subject to change)?

    0
  • Well, __call is an artifact for generic mojits to react to any action invoked, even when that action is not defined. This is an internal API, and one that we might eventually remove since it is a little confusing.

    The good news is that you, as an app develop, have full control over the specs and the actions to be executed for every mojit instance in you application, which means you really don't need __call in your frame.

    1
  • Thanks again for great advice.

    About the examle 'application.json' you gave. I was not able to use it. I think I should use "base" instead of "type" when I want to reuse an instance. Correct?

    
    [ {
      "settings": ["master"],
        "appPort": "8666",
        "specs": {
          "container": {
            "type": "ContainerMojit",
            // this one just do `ac.composite.done()` call,
            nothing else. 
              "config": {
                "children": {
                  "header": {
                    "type": "HeaderMojit" },
                  "body": {
                    "type": "DefaultBodyMojit" },
                  "footer": {
                    "type": "FooterMojit" }
                }   
              },  
          },  
          "custom-page": {
            "type": "HTMLFrameMojit",
            "config": {
              "child": {
    /*-->*/  "base": "container", // we reuse a instance mojit. then property is "base" and not "type"
                "config": {
                  "children": {
                    "body": {
                      "type": "CustomBodyMojit" // this overrule the type from the "base" container instance }
    
                  }   
                }   
              }   
            }   
          }   
        }   
    }
    ]
    
    
    0
  • Thanks caridy for great advice.

    I case one hit the same trouble. I was not able to use configuration exemple above. I think I should replace the 'type' property by 'base' when I want to reuse an mojit instance. This should be fine. Right?

    
    [ {
      "settings": ["master"],
        "appPort": "8666",
        "specs": {
          "container": {
            "type": "ContainerMojit",
            // this one just do `ac.composite.done()` call,
            nothing else. 
              "config": {
                "children": {
                  "header": {
                    "type": "HeaderMojit" },
                  "body": {
                    "type": "DefaultBodyMojit" },
                  "footer": {
                    "type": "FooterMojit" }
                }   
              },  
          },  
          "custom-page": {
            "type": "HTMLFrameMojit",
            "config": {
              "child": {
    /*------>*/ "base": "container", //Here we reuse an mojit instace, property is 'base', not 'type'
                "config": {
                  "children": {
                    "body": {
                      "type": "CustomBodyMojit" // this overrule the type from the "base" container instance }
    
                  }   
                }   
              }   
            }   
          }   
        }   
    }
    ]
    
    0
  • @Dodo, I'm not so sure I understand the question, but I will try to clarify:

    • any entry under specs is consider an instance, and it is referenced as "base" in the subsequent configuration (e.g: container definition in the example above)
    • a mojit type is the name of the folder that host the mojit, and you can create instances of it (e.g.: container instance of ContainerMojit in the example above)
    • any instance (base definition) can be extended as well (becoming some sort of meta class definition), which means that the original type + base instance + custom instance will provide configurations to form a new base defintion. (e.g.: the child instance in the example above, who inherit its configuration from container definition, whom also inherit from ContainerMojit).

    So, bottomline, that configuration seems to be correct, there might be a problem somewhere else. Feel free to provide a very small repro case and I will try to help with the error.

    0
  • @caridy, thanks for the clarification. Sorry for my double posts, I thought I failed to post the first time.

    It was just to fix (for future reader) your first configuration where the mojit instance 'container' was not referenced as "base" but as "type".

    0
  • ah, you're correct, I got confused with the question. thanks for catching that!

    1

Recent Posts

in Yahoo! Mojito