We are in the process of building a cart with the loopback API.
When adding a product (ie. 12345) to a persistent database, I am checking to see if that item already exists in my "cart". If the item exists, I am incrementing the Quantity of that item. BUT, after incrementing I need to stop the item from being added to the cart.
In the "before save" operation hook, can I cancel the item from being added to the database. I need to be able to stop the save operation.
You should use findOrCreate() like #amuramoto suggests. But to answer your question, to cancel the save, call next() with an error:
next(err);
next(new Error('Why this is cancelled...'));
It's bad practice to call a save method inside a before save hook on the same model. Infinite looping can result very easily.
Try the findOrCreate operation hook instead. It will look for an existing model based on a filter and create a new model if it isn't found.
https://apidocs.strongloop.com/loopback/#persistedmodel-findorcreate
Related
I have a question please..
how can I make a record become read-only once a particular field has a particular value. for eg. status field has the value "validate"
Think you :)
Vtiger does not offer that functionality through configuration means. However you can create a "before save" event handler. That is code that gets executed every time a record gets saved (but just before the saving is final).
In a nutshell, you have to first create the handler (a php class that extends the VTEventHandler class), then inside that class create the function handleEvent($eventName, $entityData). Inside the function you would write your logic. Finally, you have to register your handler by calling vtlib's Vtiger_Event::register.
In your event handler you can check what the value of the field was before being edited and after it was edited (but before being saved). So, if the field value prior to editing was "validate", in your code you just have to make sure that value stays that way.
You can find more on event handlers here: https://wiki.vtiger.com/index.php/Eventing
10
I have a model with a bunch computed properties and things in a ready event:
one field of the model is a json field, for which I defined sub keys if non existent.
dynamic computed properties depending on the model content are defined
the model is associated to route rep/route/:idmodel with findRecord call to a backend
when I am on the page /rep/route/123, for instance, the ready event is fired and everything is ok,
so far so good
When I go elsewhere and return to /rep/route/123 the ready event is not fired again. it seems ok since there was not another ajax call, the record is in the data storage.
But what was defined in the ready callback seems not to persist. if the ready event was not called on the page /rep/route/123 I am returning on
subkeys of the json field are not there anymore
dynamic computed propertiesare not there
that is to say if the model has been loaded from the backend previously, the ready event was fired then, but the benefits of it (some computed properties defined dynamically on the model) disappear once I return on the page where it would be needed, if no new ajax call is needed.
the only workaround I found is to call model.reload on some didInsertElement of a component in the /rep/route template, to force ajax call and fire the ready event
I also tried to call this.get('model').ready() directly but it does not work.
So what would be the best way to keep all dynamic things defined in the ready event, when quitting the page and returning on it afterwards.
thanks
I am not sure I understand your question correctly, but an Ember route with a dynamic segment will only have its model hook called when it is .entered via the URL.
Since your :123 is a dynamic segment, transitionTo will not get model hook called in your route.
I am trying to build out edit functionality for a Goal record. On the Goal index page, there is an edit button next to each goal. When clicked, each field becomes editable. Upon clicking Save, the changes are saved to the server. So far so good.
There is also a Cancel button. When a user clicks it, I need to reset the state of the model to what it was before they changed things. goal.rollback() in the controller works fine for this. Except, if the user has already clicked Save but there were server side validation failures. In this case, attempting to rollback() throws Uncaught Error: Attempted to handle event `reloadRecord` on <App.Goal:ember123:1234> while in state root.loaded.updated.invalid.
If instead I try to goal.reloadRecord I get Uncaught Error: Attempted to handle event `reloadRecord` on <App.Goal:ember123:1234> while in state root.loaded.updated.invalid.
Same deal with goal.unloadRecord. I have tried massaging the state like this:
state = goal.get('currentState') #this code makes me sad.
state.isValid = true
state.isError = false
And like this:
goal.transitionTo('loaded.saved')
To no avail. Is make zero sense to me the reloading or unloading a record should be statefull.
Any assistance would be greatly appreciated. Again, I'm trying to take a dirty, invalid record in ember and get it back to a happy state either by rolling back changes, or just reloading it from the server.
EDIT: Ember-data v1.0.0-beta.3-4-g169793e, ember Version: 1.1.2
Here's a working example, change the color then hit save.
http://emberjs.jsbin.com/OxIDiVU/44/edit
PR submitted https://github.com/emberjs/data/pull/1590
When updating a record, I do the following:
...
this.transaction.commit();
entry.on("didUpdate", this.afterSave.bind(this, success_msg));
But my function afterSave "accumulates" on the run loop (no better way to describe it). That is, the first time that I edit a record, afterSave is called once. The second time, it is called twice, and so on.
What am I doing wrong here?
EDIT
According to the model lifecycle, record.on subscribes to events. When I want to save en edited record, I basically do the following:
update the model data, updating some derived properties from the view
commit the transaction
suscribe to the didUpdate event, to notify the user and perform some final cleanup
So, every time that I edit the record, I suscribe to the didUpdate event. I expected that this was a one-time suscription. That is: I suscribe, the event is fired, I handle it, done and forgotten.
But maybe Ember practices are not supposed to work like this. It seems that I each time I call .on('didUpdate' the old suscription is still remembered. Is this so? I do not want to do this. How can I do one of these:
remove any existing suscriptions from the current record
or get a fresh record, so that I can suscribe to events from scratch. Currently I get the record with this.get('content')
I guess to avoid accumulation of subscriptions you should use one: http://emberjs.com/api/classes/Ember.Evented.html#method_one as a one time subscription. one subscribes a function to a named event and then cancels the subscription after the first time the event is triggered.
remove any existing subscription
As for the unsubscription, you could do it with on's counterpart off: http://emberjs.com/api/classes/Ember.Evented.html#method_off
Hope this helps.
Got an annoying issue.
When a user edits a field on an item, we use a OnSavingItem event handler to create some new items elsewhere in the background as it were.
Problem is the item the users edited the field of gets redirected to the item we invisible created in the background.
We want it to stay where it is... Any ideas?
thanks
If you want to disable the transfer to the item you've just created you could also consider implementing the following code:
// Before we copy the item we put notifications on to make sure we won't be transfered to the newly created item
Sitecore.Client.Site.Notifications.Disabled = true;
// Your action comes here
Sitecore.Client.Site.Notifications.Disabled = false;
Are you using the
<event name="item:saved">
Handler? If so, don't forget that this event is fired on all the new items you create as well, potentially triggering a recursive event loop.
This answer came from the SiteCore forum ... credit goes to John West
I think you could use the item:saving event or the saveUI pipeline. Use the event if you need to handle changes that occur through APIs, or use the pipeline if you only need to handle changes that occur through the user interface.
You could also consider adding the logic to the field itself.
John West Sitecore Blog
item:saved is much heavier than a processor within the saveUI pipeline. For example, item:saved is triggered during publishing which is not what you really want. I always recommend handling such customizations either on the pipeline or workflow action level.