I am attempting to use Ember.computed to setup a computed property from within one of my view's methods. I tried to use the syntax shown in this fiddle, but as you can see, it does not seem to actually do what I was hoping. Any pointers in the right direction would be much appreciated.
http://jsfiddle.net/skane/H5ma5/1/
this.set('myComputed', Ember.computed(function() {return "funky"}).property());
Steve
This won't work this way, since Ember has to do perform some of its magic. I had a look at the source of Ember and found this:
// define a computed property
Ember.defineProperty(contact, 'fullName', Ember.computed(function() {
return this.firstName+' '+this.lastName;
}).property('firstName', 'lastName'));
#method defineProperty
#for Ember
#param {Object} obj the object to define this property on. This may be a prototype.
#param {String} keyName the name of the property
#param {Ember.Descriptor} [desc] an instance of `Ember.Descriptor` (typically a
computed property) or an ES5 descriptor.
You must provide this or `data` but not both.
#param {anything} [data] something other than a descriptor, that will
become the explicit value of this property.
So the following should work in your case:
Ember.defineProperty(this, 'myComputed', Ember.computed(function() {
return "funky";
}).property());
Related
Example here: https://codesandbox.io/s/j4mo8qpmrw
Docs here: https://www.apollographql.com/docs/link/links/state.html#default
TLDR: This is a todo list, the #client query parameters don't filter out the list.
This is the query, taking in $id as a parameter
const GET_TODOS = gql`
query todos($id: Int!) {
todos(id: $id) #client {
id
text
}
}
`;
The query passes the variable in there
<Query query={GET_TODOS} variables={{ id: 1 }}>
/* Code */
</Query>
But the default resolver doesn't use the parameter, you can see it in the codesandbox.io example above.
The docs say it should work, but I can't seem to figure what I'm missing. Thanks in advance!
For simple use cases, you can often rely on the default resolver to fetch the data you need. However, to implement something like filtering the data in the cache or manipulating it (like you do with mutations), you'll need to write your own resolver. To accomplish what you're trying to do, you could do something like this:
export const resolvers = {
Query: {
todos: (obj, args, ctx) => {
const query = gql`
query GetTodos {
todos #client {
id
text
}
}
`
const { todos } = ctx.cache.readQuery({ query })
return todos.filter(todo => todo.id === args.id)
},
},
Mutation: {},
}
EDIT: Every Type we define has a set of fields. When we return a particular Type (or List of Types), each field on that type will utilize the default resolver to try to resolve its own value (assuming that field was requested). The way the default resolver works is simple -- it looks at the parent (or "root") object's value and if it finds a property matching the field name, it returns the value of that property. If the property isn't found (or can't be coerced into whatever Scalar or Type the field is expecting) it returns null.
That means we can, for example, return an object representing a single Todo and we don't have to define a resolver for its id or text fields, as long as the object has id and text properties on it. Looking at it another way, if we wanted to create an arbitrary field on Todo called textWithFoo, we could leave the cache defaults as is, and create a resolver like
(obj, args, ctx) => obj.text + ' and FOO!'
In this case, a default resolver would do us no good because the objects stored in the cache don't have a textWithFoo property, so we write our own resolver.
What's important to keep in mind is that a query like todos is just a field too (in this case, it's a field on the Query Type). It behaves pretty much the same way any other field does (including the default resolver behavior). With apollo-link-state, though, the data structure you define under defaults becomes the parent or "root" value for your queries.
In your sample code, your defaults include a single property (todos). Because that's a property on the root object, we can fetch it with a query called todos and still get back the data even without a resolver. The default resolver for the todos field will look in the root object (in this case your cache), see a property called todos and return that.
On the flip side, a query like todo (singular) doesn't have a matching property in the root (cache). You need to write a resolver for it to have it return data. Similarly, if you want to manipulate the data before returning it in the query (with or without arguments), you need to include a resolver.
I have a wrapping component, which yields some other component in itself. (Think about form control group or a table cell component).
To make it as flexible as possible I pass attrs to the hash property. And all component will set hash on itself.
Ember.Component.reopen({
init: function(){
this._super();
this.setProperties(this.get('hash'));
}
});
http://jsbin.com/suvenijuxu/1/edit?html,js,output
It works fine with Strings but not with objects. In my-wrapper component attrs.model.name has the correct value (see the template), but after attrs is passed to the property hash and set by setProperties it is transformed to MutStream. (see console.log)
Why does this transformation happens? Is this the expected behavior? Is my approach considered as an anti-pattern? Is there a workaround? What does MutStream or MUTABLE_REFERENCE mean?
I'm looping through a content of an ArrayController whose content is set to a RecordArray. Each record is DS.Model, say Client
{{# each item in controller}}
{{item.balance}}
{{/each}}
balance is a property of the Client model and a call to item.balance will fetch the property from the model directly. I want to apply some formatting to balance to display in a money format. The easy way to do this is to add a computed property, balanceMoney, to the Client object and do the formatting there:
App.Client = DS.Model({
balance: DS.attr('balance'),
balanceMoney: function() {
// format the balance property
return Money.format(this.get('balance');
}.property('balance')
});
This serves well the purpose, the right place for balanceMoney computed property though, is the client controller rather than the client model. I was under the impression that Ember lookup properties in the controller first and then tries to retrieve them in the model if nothing has been found. None of this happen here though, a call to item.balanceMoney will just be ignored and will never reach the controller.
Is it possible to configure somehow a controller to act always as a proxy to the model in all circumstances.
UPDATE - Using the latest version from emberjs master repository you can configure the array controller to resolve records' methods through a controller proxy by overriding the lookupItemController method in the ArrayController. The method should return the name of the controller without the 'controller' suffix i.e. client instead of clientController. Merely setting the itemControllerClass property in the array controller doesn't seem to work for the moment.
lookupItemController: function( object ) {
return 'client';
},
This was recently added to master: https://github.com/emberjs/ember.js/commit/2a75cacc30c8d02acc83094b47ae8a6900c0975b
As of this writing it is not in any released versions. It will mostly likely be part of 1.0.0.pre.3.
If you're only after formatting, another possibility is to make a handlebars helper. You could implement your own {{formatMoney item.balance}} helper, for instance.
For something more general, I made this one to wrap an sprintf implementation (pick one of several out there):
Ember.Handlebars.registerHelper('sprintf', function (/*arbitrary number of arguments*/) {
var options = arguments[arguments.length - 1],
fmtStr = arguments[0],
params = Array.prototype.slice.call(arguments, 1, -1);
for (var i = 0; i < params.length; i++) {
params[i] = this.get(params[i]);
}
return vsprintf(fmtStr, params);
});
And then you can do {{sprintf "$%.2f" item.balance}}.
However, the solution #luke-melia gave will be far more flexible--for example letting you calculate a balance in the controller, as opposed to simply formatting a single value.
EDIT:
A caveat I should have mentioned because it's not obvious: the above solution does not create a bound handlebars helper, so changes to the underlying model value won't be reflected. There's supposed to be a registerBoundHelper already committed to Ember.js which would fix this, but that too is not released yet.
How can I bind an Ember Map value to a TextField value. Let's say I have this configuration:
App.AppsController = Em.Controller.extend({
selections: null
});
App.AppsRoute = Ember.Route.extend({
setupControllers: function(controller, model) {
controller.set('selections', Ember.Map.create());
}
});
And in my template:
{{view Ember.TextField valueBinding="bindingToMap"}}
I have tried to valueBinding="controller.selections.somekey" where somekey is a key from my map. However, the value is never bound. Note that initially the map is empty. Can this be the root of the problem?
EDIT:
I have also tried to use the binding with an integer value in the controller and it works. So the problem comes when I bind a more complex data structure such as a Map. I couldn't find anything in the docs explaining how to bind a map.
Caveat: I'm pretty new to Ember myself.
Looking at the implementation of Ember.Map, I don't think you can currently (in 1.0.0-pre2) do this. Ember.Map implements create, get, and set, but is not a normal Ember object. So among other things, "properties" in a map aren't really properties, and there's no observables support. The handlebars implementation relies heavily on observable support, so I think what you're doing won't work.
Someone correct me if I'm wrong, but this is what I'm looking at in the 1.0.0-pre2 code:
var Map = Ember.Map = function() {
this.keys = Ember.OrderedSet.create();
this.values = {};
};
/**
#method create
#static
*/
Map.create = function() {
return new Map();
};
Map.prototype = {
/**
Retrieve the value associated with a given key.
#method get
#param {anything} key
#return {anything} the value associated with the key, or undefined
*/
get: function(key) {
var values = this.values,
guid = guidFor(key);
return values[guid];
},
...
Point being, it implements its own get (and create) rather than extending Ember.Object...so no observable support. Though I might have missed it if it reopen's later or something.
EDIT:
Also, not really what you asked, but if you're building an interface that relies on the existence of some key, you should really probably be defining your own model class that has these keys as properties. You can still set them to null if they're "not set". If you also need the ability to set arbitrary keys, make one of your properties an Ember.Map and call it otherProperties or something, and put them in there. But if your view depends on a known key, it should be a defined property.
i tried to implement the file upload via doctrine/lifecycle callbacks as described here:
http://symfony.com/doc/current/cookbook/doctrine/file_uploads.html#using-lifecycle-callbacks
So far it works, but the PrePersist/PreUpdate Event is not fired, the function "preUpload" is not called.
Functions like "upload" and "removeUpload" triggered by other lifecycle events are called correctly.
Does anyone have an idea why the event is not fired or a solution for this problem?
Thanks
I have another solution to this problem:
My entity has a field "updatedAt" which is a timestamp of the last update. Since this field gets set anyway (by the timestampable extension of Gedmo) I just use this field to trick doctrine into believing that the entitiy was updated.
Before I persist the entity I set this field manually doing
if( $editForm['file']->getData() )
$entity->setUpdateAt(new \DateTime());
This way the entity gets persisted (because it has changed) and the preUpdate and postUpdate functions are called properly.
Of course this only works if your entity has a field that you can exploit like that.
You need to change tracking policies.
Full explanation.
there's a much simpler solution compared with changing tracking policies and other solutions:
in controller:
if ($form->isValid()) {
...
if ($form->get('file')->getData() != NULL) {//user have uploaded a new file
$file = $form->get('file')->getData();//get 'UploadedFile' object
$news->setPath($file->getClientOriginalName());//change field that holds file's path in db to a temporary value,i.e original file name uploaded by user
}
...
}
this way you have changed a persisted field (here it is path field), so PreUpdate() & PostUpdate() are triggered then you should change path field value to any thing you like (i.e timestamp) in PreUpdate() function so in the end correct value is persisted to DB.
A trick could be to modify the entity no matter what..on postLoad.
1 Create an updatedAt field.
/**
* Date/Time of the update
*
* #var \Datetime
* #ORM\Column(name="updated_at", type="datetime")
*/
private $updatedAt;
2 Create a postLoad() function that will modify your entity anyway:
/**
* #ORM\PostLoad()
*/
public function postLoad()
{
$this->updatedAt = new \DateTime();
}
3 Just update that field correctly on prePersist:
/**
* #ORM\PrePersist()
* #ORM\PreUpdate()
*/
public function preUpload()
{
$this->updatedAt = new \DateTime();
//...update your picture
}
This is basically a slight variation of #philipphoffmann's answer:
What i do is that i modify an attribute before persisting to trigger the preUpdate event, then i undo this modification in the listener:
$entity->setToken($entity->getToken()."_tmp");
$em->flush();
In my listener:
public function preUpdate(LifecycleEventArgs $args)
{
$entity = $args->getEntity();
if ($entity instanceof MyEntity) {
$entity->setToken(str_replace('_tmp', '', $entity->getToken()));
//...
}
}
Another option is to display the database field where the filename is stored as a hidden input field and when the file upload input changes set that to empty so it ends up triggering doctrine's update events. So in the form builder you could have something like this:
->add('path', 'text', array('required' => false,'label' => 'Photo file name', 'attr' => array('class' => 'invisible')))
->add('file', 'file', array('label' => 'Photo', 'attr' => array('class' => 'uploader','data-target' => 'iddp_rorschachbundle_institutiontype_path')))
Path is a property managed by doctrine (equal to the field name in the db table) and file is the virtual property to handle uploads (not managed by doctrine). The css class simply sets the display to none. And then a simple js to change the value of the hidden input field
$('.uploader').change(function(){
var t = $(this).attr('data-target');
//clear input value
$("#"+t).val('');
});
For me, it worked good when I just manually called these methods in the controller.
Do you have checked your metadata cache driver option in your config.yml file?If it exists, just try to comment this line:
metadata_cache_driver: whateverTheStorage
Like this:
#metadata_cache_driver: whateverTheStorage