Somewhere in my code, I hit a bug. I put a breakpoint to try and see what is happening. When I inspect the object "foo" in the console I get:
foo.toString() > "<App.Foo:ember661:174009>" // all good
foo.get('isLoaded') > true
foo.get('isValid') > true
Yet:
foo.get('name') > null // Whereas it definitely has a name.
When I look at the Network tab in the developer tools, I can see that it is still "finishing" to load the record. For the corresponding URL, it says: "pending".
What is this model state? How do you know when a model is "fully" ready?
UPDATE: per my comment to Mike, I should have added that I am inspecting this record within a registerBoundHelper function. So I guess there is a context issue that I am missing. Indeed:
... foo template ...
{{ name }} // properly set to a value
{{ my_helper this }}
... helpers ...
Ember.Handlebars.registerBoundHelper('my_helper', function(foo) {
return foo.get('name'); // name property is null!!
});
I must be missing something obvious?
Thanks,
PJ
What is this model state?
Can't tell given the info you provided, but to find out from console you could try this:
foo.stateManager.get('currentPath') > should be something like "rootState.loaded.saved"
Then have a look at states.js source code for details on that state.
How do you know when a model is "fully" ready?
Depends what you mean by fully and ready. Some tricks to help you see what's what:
Show me the raw data for a model
foo.get('data')
foo.get('data.attributes')
Get console log output when the record transitions between states
record.set("stateManager.enableLogging", true)
Answering my own question, in case it helps someone else...
This strange behaviour came from a context issue for the helper. It was pretty "deep" in a view (several nested levels down) and I am using a combination of {{partial}} and the new {{render}} that you can now use multiple times (on master). I'd lie if I were to say I am totally clear with what was happening, but I tried various contexts switches and it ended up working.
So I guess if you hit something like that, double check your helpers's context...
Related
I have a form here with a nested table - where each table can dynamically grow, i.e., the inner table (w/ Transit No and Account No) and the outer table (Accounts by ID No). Here is an example:
(Behind the buttons:
Add - $.parent.tbl.Row.instanceManager.addInstance();
Remove - $.parent.instanceManager.removeInstance(this.parent.index); (In
production I make sure there is at least one row to remove...)
In the definition for each table I do not have checked 'Repeat Table for Each Data Item'. This works great. However I did try with that checked and the outcome was the same.
Now, when I email the form and open the attachment, this is what I see:
You can see that the second table didn't make it, and apparently a row was added to the inner table in the first, without any data.
Any ideas on what's going wrong here? And what I can do about it?
Unfortunately I'm not sure what's wrong with your form but I have made a similar form that works - so I can show you how I did it and list a few things that I can think of that can cause problems.
This is what my form looks like and when I e-mail it, it comes out exactly the way it is:
(It has repeatable parent- and childsubforms like yours)
I did it entirely with JS though, no FormCalc and Dollar $igns :D
When a button is pressed I call a function from a Scriptobject.
These are the main parts of my script inside my functions:
Adding a Subform:
var oNewInstance = subform.instanceManager.addInstance(1);
Deleting a Subform:
if (subform.instanceManager.count > subform.instanceManager.occur.min)
{
subform.instanceManager.removeInstance(subform.index);
}
And these are my subforms' properties (in German, but you can figure it out :P):
Your problem might also have completely other reasons though, make sure you don't have any changes in an initialize,docReady, preSubmit and similar actions that occur between sending and opening the sent PDF.
Also before sending it as an e-mail you have to save it in Acrobat as a Reader Extended PDF:
Besides that I've noticed that sometimes problems can occur due to the target version (Selectable in LCD under File > Form Properties > Defaults).
It helped me sometimes to set it to the newest one.
I've seen a SO post on this but can't seem to find it.
My results are rendering in my template with the object_name as
{'sessions__sum': 29649}
instead of just
29649.
How can I show just the sum? Thank you.
Update
I realize, out of lack of knowledge, I may not have asked my question correctly, so below is my view and a screenshot of my template, rendered in the browser. Hopefully this will help clear things up.
view
year_weekly_filter.filter(created__week_day=1).aggregate(Sum('sessions'))
monday2014 = year_weekly_filter.filter(created__week_day=2).aggregate(Sum('sessions'))
Template
{{ monday2014 }}
ScreenShot - how its rendering in the browser
You should note that: "aggregate() is a terminal clause for a QuerySet that, when invoked, returns a dictionary of name-value pairs." - Django Docs
If you just want a single value to be returned to a variable and not a dict, use .get like so:
monday2014 = year_weekly_filter.filter(created__week_day=2).aggregate(Sum('sessions')).get('sessions__sum',0)
Do you mean the {{object}} in the template is rendered by the dictionary object?
In this case, the key is accessed in this way.
{{object.sessions__sum}}
and you may get help in this and the related documentation is here.
I don't have enough points to add a comment, so I leave my guess here.
I have the following Ember.js code (in a model):
subdata: DS.hasMany('App.Subdata'),
message_subdata: function() {
return this.get('subdata').filterBy('tag', 'message');
}.property('subdata', 'subdata.#each')
This worked just fine in RC7. In RC8+, I know they made changes to the way that observers fire, but for the life of me, I can't figure out how to get it working again. I know it says to make sure to call get before observing the property, but I'm using this property in a template, so doesn't the template have to get the property?
Right now, when the page first loads, none of the data gets shown because none of the subdata is loaded yet. That's how it's always been. But in RC7, as soon as the records were loaded, it would fire the observers and update the page. Now, for some reason, the observers aren't being update and the page won't update. The only way I can seem to force it to update is by changing the subdata property (or simulating a change with notifyPropertyChange).
How can I get my properties to work as they did in RC7?
EDIT: I thought I would give a quick update on how I did sorting AND filtering. It's probably not the best way, but I fiddled for a while to land on this solution.
subdata: DS.hasMany('App.Subdata'),
message_subdata_filtered: Ember.computed.filterBy('subdata', 'tag', 'message'),
message_subdata: Ember.computed.sort('message_subdata_filtered', function(a,b) {
return a.get('timestamp') - b.get('timestamp');
});
There might be a way to do it in one line, but this works for me.
I guess the new way of doing computed arrays is by using something like this:
subdata: DS.hasMany('App.Subdata'),
message_subdata: Ember.computed.filterBy('subdata', 'tag', 'message')
As part of an attempt to port a fairly large/complex existing application to the Ember world, I'm generating and compiling named Handlebars templates dynamically, and associating views with them, using the technique:
var template = Ember.Handlebars.compile("some handlebars stuff");
Ember.TEMPLATES["myTemplate"] = template;
var view = Ember.View.create({
templateName: "myTemplate"
});
One of the things I'd like to do is be able to recompile new/different Handlebars template markup which overwrites the template named "myTemplate" and have it be accessible to views at that name.
I'm getting unexpected results trying to do this - a couple fiddles that illustrate the problems:
First fiddle - Shows what happens if you wait before rendering a view after the named template contents have changed.
Second fiddle - Shows what happens if there's no delay before rendering a view after the named template contents have changed.
There's obviously some magic under the hood that I'm not understanding. Can anyone shed some light on this?
UPDATE:
I went through the source code for Ember.View and the container module, and came to realize that I could solve the problem in the First fiddle by overriding the "template" computed property in a way that skips the container cache lookup. I've put up another fiddle here to demonstrate the solution I found.
This seems to be working the way I'd like it to - but - it feels like I might be fighting with the framework and "unhooking" from the container in a way that might bite me later. Is there a better, more Ember-esque way to accomplish what I'm trying to do? Will the hack I found break things?
UPDATE 2
I've also discovered that it's also possible to simply call
view2.get('container').reset();
before appending view2 in the First fiddle. Seems cleaner/safer, but is it "legal"? I've updated the First fiddle to illustrate this.
(in the second fiddle, both views show the second template)
This is because view1.appendTo($("#target")); just schedules the append, actual view rendering does not happen until end of the run loop. Before that happens, you've set Ember.TEMPLATES["myTemplate"] = template2;
(in the first fiddle, both views show the first template)
Pretty sure this is because ember container caches template fx, but not 100% on that. Checking...
I'm going to call this one answered. As I mentioned in my second comment, I'm using the solution shown in this fiddle in my project, along these lines:
mYiew.get('container').reset();
There's some discussion about the container not being intended to be used as an API here: https://github.com/emberjs/ember.js/commit/5becdc4467573f80a5c5dbb51d97c6b9239714a8 , but there doesn't seem to be any mention of using the container from Views for other use cases.
Also, a View's container can be accessed directly (at ".container") - meaning the devs haven't made it "hard" to get to the way they have for an Application's ".__ container __". This might suggest something about how they intend it to be used.
Since a View having the ability to clear its cache whenever it wants to doesn't seem to me to be unreasonable or a bad practice, I'm using the above mentioned solution...at least until someone sets me straight with a better idea (or a cache API).
I am trying to show a TopController property in a TopView template. In TopView, I have sectionBinding: 'controller.section'.
From my understanding of Ember.js, in TopView, the controller property should refer to my TopController. Yet it seems to refer to ApplicationController? Read on:
In my router, I have router.set('topController.section', 'index');... But that doesn't seem to do anything in this case. Changing it to router.set('applicationController.section', 'index'); works and the {{section}} part in the TopView template changes to "index".
I have created two fiddles showing my issue. The first one doesn't work:
FAULTY -> http://jsfiddle.net/8tQ4q/4/
The second one does work:
WORKS -> http://jsfiddle.net/8tQ4q/5/
The only difference is the topController / applicationController part in router.set(). Any idea what I am doing wrong?
I'm not sure why you're expecting topController to be connected to TopView. You haven't done anything to make this connection. I think you may be confused because connectOutlet('top') would create a TopView that is connected to topController. However, you aren't doing this anywhere in your app.
You also don't need the sectionBinding. If you have a controller defined on your view, it will be the default context.
I think what you want to do is this:
router.get('topController').set('section', 'index');