Let's say I want to perform custom logic only, say, when a user's verified field changes from false to true (in order to make sure they are allowed to be performing this operation). Is there a way in Cloud Code to see what the 'current', i.e. about-to-be-overwritten value of a field is?
I would look at changedAttributes(), previousAttributes() and previous("columnName") to see if these have been exposed in the beforeSave handler yet.
Update note: none of those methods help.
The only other option I've seen in some older questions is to check object.existed() and in that case do a get() request to load the original values before the save. Obviously this causes 2 API requests per save.
It would be great to hear back if the changed/previous methods work.
Update
I have since done some more thorough testing, and the only option is to get() the previous version of the record. Nothing else works. This of course requires that you do it in the before-save handler.
Related
This relates to this question:
Set URL query parameters without state change using Angular ui-router
(I dont have enough points for a comment)
I'm using $state.go('state.name', {params}, {notify:false}) to update my url params and it works well.
The problem is I have defined 'resolve' services for this route and they are being called, and I don't really want that to happen, as it is unnecessary calls to the server.
I would expect {notify:false} to skip that too, Is there a way to skip the resolving?
Or even better - another elegant way to update state params with ease? (instead of $state.go()) ?
I'm running in to an issue in that I need to get one value in a cucumber statement, and then give that value to another statement.
Specifically I am getting a JSON object from one page (where that object gets sent to an api endpoint as a preference) and then using information out of that after I query the api, which happens in a completely separate step.
I am suspecting that I have to write the value somewhere, and then pull that value when the step that needs it comes up, but I'm kind of at a loss for doing that as well.
I can provide any further needed details, thanks for any help!
Definitely a rookie question - to which the answer is to use instance variables - #variable_name = get_method in the helper method your step calls.
The specific case I've got in mind is as follows: an AjaxFormComponentUpdatingBehavior("onchange") is added to a TextField in a form. The behavior verifies the text for certain conditions (either the model object or the form component model, doesn't matter), based on which it might display a message (or hide it, if it has already been shown).
The problem is, there are also validators added to the TextField. One of the possible (and likely) scenarios consists of the user typing in, first, a value that causes the message to be displayed by the AJAX request. If, then, he/she types in a value that doesn't pass validation, the message should disappear, but it does not.
Apparently, either the onUpdate() method for the AJAX behavior is not called at all, or I am failing in my attempts to insert a check for non-validated entries (I have tried to test for both null values and empty strings, to no avail; I have no idea what exactly Wicket's validators do to models when data is invalid).
I am wondering if someone who actually understands validators (or AJAX, actually) has any ideas on where the problem could be.
I can post edit and post code if someone tells me this is not a general issue tying validators and AJAX, but most likely a programming mistake. I still believe the former and thus I'll refrain from posting code sections, in order to keep the discussion on an API/theoretical frame.
Thanks.
When using an AjaxFormComponentUpdatingBehavior, if any of the IValidators fail their validation, onError() will be called instead of onUpdate(). Wicket will effectively prevent invalid user input from reaching the IModels in your components, so the component's ModelObject will not be changed at all. The invalid input will probably remain available by means of getInput()/getConvertedInput() (not sure if it will in an AJAX scenario, it sure is in a traditional form submission).
However, take into account that IFormValidators are not executed when using this mechanism. If you've got any, you might be interested in overriding getUpdateModel() so that AjaxFormComponentUpdatingBehavior will not bring maybe-invalid user input into your IModels, and set modelobjects manually when you're certain user input is valid.
Regarding your specific case, you could perform all the required logic in onError() (or rely on Models that will grab data from somewhere else), and just add the components that need refreshing to the AjaxRequestTarget. This is probably what's missing in your scenario.
We usually follow the convention of doing a redirect after every post, which is ideally very clean. But usually there is a requirement to give the user feedback about what has been updated.
When i do a post followed by get i wanna show the same page with the notification about the updation being done, which makes the GET very clumsy with the extra status of whats being updated. Am i missing something here?
which is ideally very clean
debatable.
which makes the GET very clumsy with the extra status of whats being updated
...and that's one of the main reasons why.
Trying to pass transactional data via the session is a very bad practice.
The solution I've used is to use a front controller for sequences of forms (not a front controller for the whole site!) but in general trying to avoid the scenario where there is a sequence of forms to be posted
I have an entity in my coredata document based application.
I have certain default values that get created when a new document is created for that entity.
I need to be able to allow users to add and remove from that list (easily done), but prevent users from deleting the default values (cant find the answer).
Thanks for your response, that is a good option in this case I think I will use it.
I was wondering though if anyone knows how a person can VALIDATE a delete.... so if a person clicks on the delete button, it will go through some logic (complex or simple, depending on the application) then either ignore the click or actually delete the object.
I've looked at the method validateForDelete: but there is very little documentation on it and i'm not sure if this is the intended use of the method.
You could add a boolean attribute to your entity that indicates whether or not a value is a default. You could then deactivate the delete button if the currently selected value is a default, using the enabled binding.