Model.js setup function treating arguments as attributes --> overwriting "init", badness

[George S]

I'm running into some strange behavior since git-pulling framework/
jquery. In particular, when I try to instantiate one of my models
with a single argument to the init function, as:

new Myproject.Models.Modelname() // works fine
new Myproject.Models.Modelname(arg) // if arg.init is defined,
craziness ensues!

As far as I can tell, here's what's happening...

1. class.js is calling model.js's instance-wise setup function:
args = inst.setup.apply(inst, arguments);

2. which in turn calls attrs using *my argument* as the attribute
set:
this.attrs(attributes);

3. Now, the new object's init function is replaced with the
*argument's* init function --- not at all what I wanted. So, instead
of running the "init" function defined by Myproject.Models.Modelname,
I get a new object which has been "initialized" via the argument's
init function.

Please let me know if I'm explaining this clearly. I can send example
code if that would help.

Best,

George

[George S]

My confusion seems to be about how to write an initialization routine
for my model objects:

I've been writing one called init, like:

$.Model.extend('Cookbook.Models.Recipe',
/* @Static */
{ },
/* @Prototype */
{
init: function(a) {
alert("This text should alert when a new recipe is
initialized" + a);
}
})

This was the convention defined in class.js that I've been used to...
but it appears perhaps I should be naming this function "setup"
instead of init? Can someone please confirm?

Thanks again,

George

[Justin Meyer]

Well, it depends on what you want to do.  Class now supports setup and init methods that happens when a class is created.  Setup is used for classes where you 99% of the time want the standard initialization routine to run.  Init is for all the other situations.  Controller is the best example of this.

In 2.0's controller's we always had to do:

init : function(el, options){

  this._super(el, options)

  

  //  custom initialization function here

}

I would even forget to call _super.  And, if the creator of the library is having problems, there's a problem.

So, I made it possible for classes to have 2 setup type functions.  Model uses the same pattern (doing most of it's work in setup), so that you don't have to call this._super to get your model setup correctly.

You should still be able to use init, it's just model's setup code will have already run.

Justin Meyer

Jupiter Consulting
\Development\Training\Support
847-924-6039
justin...@gmail.com

 George

--
You received this message because you are subscribed to the Google Groups "JavaScriptMVC" group.
To post to this group, send email to javasc...@googlegroups.com.
To unsubscribe from this group, send email to javascriptmv...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javascriptmvc?hl=en.

[George S]

Justin,

Can you explain the implications for passing arguments when calling
new() to create a model object? Consider this pair of models, where
recipe's init takes an ingredient as its argument:

$.Model.extend('Cookbook.Models.Recipe',
{ }, {
init: function(ingredient) {
alert("Recipe initialized with ingredient: " + ingredient);
}
});

$.Model.extend('Cookbook.Models.Ingredient',
{ },{
init: function() {
alert("Ingredient Initialized...");
}
});

I now make two calls on page load:

var i = new Cookbook.Models.Ingredient();
var r = new Cookbook.Models.Recipe(i);

What alerts should I expect? (I'd expect "Ingredient initialized"
followed by "Recipe initialized" -- but I get "Ingredient initialized"
twice, because model.js's setup is overwriting my new recipe's init
function with the ingredient argument's own init.) Is this the
intended behavior (in which case I just don't understand), or a bug?

Thanks,

George

[Justin Meyer]

Well, you probably shouldn't pass an ingredient that way.  Instead your code should look like:

var i = new Cookbook.Models.Ingredient();

var r  = new Cookbook.Models.Recipe({ingredient: i});

Model.prototype.setup expects an object of name-value pairs.  If you REALLY want to create a Recipe with just an ingredient, you'd have to do it like:

$.Model.extend("Recipe",{

  setup : function(ingreident){

    this._super({ingredient: ingredient})

  }

})

Justin Meyer

Jupiter Consulting
\Development\Training\Support
847-924-6039
justin...@gmail.com

 George

[Justin Meyer]

Also, if you did it that way, you wouldn't be able to supply any other properties.

Justin Meyer

Jupiter Consulting
\Development\Training\Support
847-924-6039
justin...@gmail.com

[George S]

I guess I'm more interested in setting my new object's properties
myself (in my initialization code), rather than having them
automatically set. For instance, I'm often passing some configuration
parameters that don't properly belong to the model; but the model's
init routine encapsulates the logic to derive its own parameters from
them. In other words, there's some meaty logic in the init (or setup)
routine, and that logic might take input parameters that shouldn't
ultimately remain attached to the newly initialized object.

(In practice what I'm doing is passing in an RDF graph to the init
function, then querying that graph in init() to figure out the
properties my object should have.)

If I use setup() instead of init() I can pass in arguments basically
the way I want -- but I find it somewhat strange that my model
initialization shouldn't parallel my controller initialization more
closely. Then I can call this._super() without having to pass any
attributes along...

Thanks as always for the speedy replies!

-George