Support for global models #839

Merged
merged 4 commits into from Dec 6, 2012

Conversation

Projects
None yet
4 participants
Collaborator

caridy commented Dec 6, 2012

  • a parent mojit can register a custom global model instance
  • a child mojit can ask for a regular model and receive a global model if exists
Contributor

isao commented Dec 6, 2012

We've been planning to deprecate "app-level" mojits, which are really a kind of convoluted global model containers AFAIK. We should proceed to officially deprecate app-level if we go with this.

This is an improvement, but IMO it'd be preferred to have a parent mojit (or the thing that owns page-scope) inject/specify shared resources and data.

Top-down injection would simplify control and optimization with respect to order of execution. Whereas the global model would have to deal with invocations bottom-up. I'm thinking of the case of mojit A request/context -> webservice I, ws II.. etc -> modelled data, and mojit B -> ws I, ws III -> modelled data

@drewfish drewfish commented on an outdated diff Dec 6, 2012

lib/app/addons/ac/models.common.js
@@ -13,6 +14,8 @@ YUI.add('mojito-models-addon', function (Y, NAME) {
'use strict';
+ var _clientCache = {};
@drewfish

drewfish Dec 6, 2012

Contributor

A short comment would by nice, something like "global model cache when on the client".

@drewfish drewfish commented on the diff Dec 6, 2012

tests/unit/lib/app/addons/ac/test-models.common.js
+ instance: {}
+ }, adapter);
+
+ var localModel = {
+ name: 'local'
+ };
+ var globalModel = {
+ name: 'global'
+ };
+
+ Y.mojito.models.cuba = localModel;
+ addon.registerGlobal('cuba', globalModel);
+
+ model = addon.get('cuba');
+ A.isObject(model, 'registered model should return an instance');
+ A.areSame(globalModel, model, 'global registered should have priority over local models');
@drewfish

drewfish Dec 6, 2012

Contributor

Really? I think that might be controversial. As an app developer I might want my local model to override my global model.

Looking at the implementation of get() I think the following will result in the local model being returned from both calls:

Y.mojito.models.cuba = localModel;
addon.get('cuba');  // returns localModel
addon.registerGlobal('cuba', globalModel);
addon.get('cuba');  // returns localModel
Contributor

drewfish commented Dec 6, 2012

"app-level" mojits are really something different. An "app-level" mojit isn't really a mojit, it's just a collection of resource shared with all other mojits.

The YAF convergence design has a feature in it where the user can define app-level models. This is especially useful when running client side (on the page) where you might only want one "user" model for example.

Contributor

drewfish commented Dec 6, 2012

Yeah, a lot of this would be improved with the data scopes we've been wanting. I'm OK with most of this PR until we have those, though.

Collaborator

caridy commented Dec 6, 2012

@drewfish is right, the use case I'm trying to solve here is:

As a dev, I want to create an instance of a model and share it with other mojits in the page.

These global models are really page models since they should be part of the page data scope that is a long living structure, but we are not there yet. In fact, the whole re-hydration process has to be implemented as well, but this is the first step in that direction.

Contributor

isao commented Dec 6, 2012

Yes, I understand, and again, it's simple enough and better than what exists. I'm just wary of opening the door to globals and treating apps like web pages.

Instead of register/request globally, can this be scoped to ancestor mojit?

Anyway, +1 with these caveats

Contributor

drewfish commented Dec 6, 2012

+1

Collaborator

caridy commented Dec 6, 2012

@isao as today, mojits are doing PULL to get a model, which is just fine. The problem is when we want to control the mojit from outside, and use some kind of PUSH into the mojit to get control over the model that the mojit will ended up using. For that, parent-child is not enough, because in many cases, we want to define the data structure at the page/app level, and that's what this PR resolves. Eventually we will have configurations and stuff that can let the mojito framework to do more, but for now, a mojit is responsible for registering it.

@caridy caridy added a commit that referenced this pull request Dec 6, 2012

@caridy caridy Merge pull request #839 from caridy/global-models
adding support for global models:

- a parent mojit can register a custom global model instance
- a child mojit can ask for a regular model and receive a global model if exists
9874480

@caridy caridy merged commit 9874480 into YahooArchive:develop Dec 6, 2012

1 check was pending

default The Travis build is in progress
Details
Contributor

rwaldura commented Dec 6, 2012

Guys:
I think I understand what we're trying to accomplish here, but can you make sure you document this thoroughly?
I.e. can you draft something for @zhouyaoji , or patch the existing doc?
http://developer.yahoo.com/cocktails/mojito/docs/intro/mojito_mvc.html#models
which maps to
https://github.com/yahoo/mojito/blob/develop/docs/dev_guide/intro/mojito_mvc.rst
Thanks!

Collaborator

caridy commented Dec 6, 2012

@rwaldura I'm not so sure we are ready for primetime for this new feature. Let's call it experimental for now!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment