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.
Related
Multiple required fields from bulk edit form are not displayed. The labels for that fields appear on form but the textboxes don't appear. I think this happens because we have scripts that run for that fields. I tried to edit customizations.xml and to put BehaviorInBulkEditForm = "Enabled" but it is not working. Is there another way to enable javascript?
As per the Form XML schema, the BehaviorInBulkEditForm attribute goes on the <event> element, careful you're not putting it somewhere else.
The valid values, as per Microsoft KB 949941, are:
Enabled
If you use this value, the field is enabled. Additionally, the code for the event is run when the event is called.
Disabled
If you use this value, the field is disabled.
EnabledButNoRender
If you use this value, the field is enabled. However, the code for the event is not run when the event is called.
I would recommend to stay away from unsupported customizations which will eventually break in future updates.
If it’s worth, then move all the logic to post-update or pre-update plugins which is fail proof server side implementation rather than client side js route.
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.
I have some property OwnerId that has each page in my application. I need these property to create HttpWebRequest and get some data. But when the application deactivated and activated again the page as deleted and created again, so these property is 0. I can't save these property in PhoneApplicationPage.State , because these property is different for different pages, so when I go twice back I can get error. I think to take it property after application activated from NavigationService.BackStack pages.But I'm not sure it is right. How can I do it ?
Aram .. thanks for explaining the question better.
Now, while your application is in the foreground, how are you managing all these different OwnerIDs? A collection? I am guessing you don't have multiple instances of the same page; but rather pass query parameters along to indicate which OwnerID/UserID should be used to display appropriate user info. You could put the whole collection in State dictionaries with a key & hydrate/dehydrate during the application lifecycle. Makes sense?
Thanks!
I'm not 100% clear on whether you need a setting for each page or just a single setting for the app. In either case your best option (IMO) is IsolatedStorageSettings (http://msdn.microsoft.com/en-us/library/system.io.isolatedstorage.isolatedstoragesettings(v=vs.95).aspx)
If you just need a single setting then there's no problem but if you need one for each page you will need to do something ugly like using the page name as the key.
I have two tables, users and tokens.
Each user have a activated field and each token have the {id, token, user_id, created} fields.
The way the app should work is:
On the creation, the app will -
make sure that the activated field is empty (to avoid manipulations to the submitted data).
a token will be created in the tokens table.
On update, the app will -
NOT create a new token.
NOT allow an update of any kind to the activated field.
check if a new email has been submitted, and if so: will create a new token and set the activated field to false.
I know how to activate the account through the controller and how to setup the router for that.
What I need is mainly the model configuration.
For example:
I think that the token creation should be done in the afterSave method, so - how do I determine if the method is called by an update or by a create operation?
Thanks for any help
yossi you can also specify the fields that should be saved from the form though - a whitelist of fields it is ok to save in you $this->save() call. That way you can stop a hacker passing an ID in the request, and you should just set it in the controller yourself then with $this->Token->id = whatever you have, I would personally use saveField ('activated) in conjunction with this (just saves a single field!). Fat models is best if you can but get it working first then refactor it if you have got stuck. Better than wasting lots of time writing perfect first time.
You question is unclear. If you have a default value for a field, then why not set it in the database rather than doing something in aftersave? If you need to do something that should be done only in certain circumstances, then write a custom method in your model to perform the tasks you want either on creation or update.
Edit
So, if your record has an id, then you know it exists in the database. So, the simple thing to do is (in any method) check to see if the model has an id field and that it is not empty. If it's empty, then you know that you are creating a record and you can do x task. If it isn't, then do y task.
if(isset($modelData['ModelName']['id']) && !empty($modelData['ModelName']['id'])){
//This is an update
} else {
//This is a new record
}
I've been having a look at several MVC frameworks (like rails, merb, cakephp, codeignitier, and similars...)
All the samples I've seen are basically plain and simple CRUD pages, carrying all the infr needed in the querystring and the posted field values.
I've got a couple of apps made with some sort of framework built with classic asp.
This framework handles some CRUD stuff a little more complex than the examples I found.
Something like master-detail, filtering by example, paging, sorting and similars.
I have a controller class that it's just a finite state machine, that goes thru diferent states (like new, browse, filter, show, etc.), then performs the appropiate action depending on the event raised and finally retrieves the neede info to the calling page.
To achieve this I have several hidden inputs to keep the state of the web page (like current id, filter criterias, order criterias, previous state, previous event, well, you get the idea)
What do you think would be the finnest approach to achieve this kind of funcionality?
hidden inputs built in the view and used from the controller??? (I guess that would be the equivalent of what I'm doing right now in classi asp)
--
(added in response to tvanfosson)
basically, my question refers to the third category, the context-dependent setting (in respect to the other two categories I agree with you) the info I was storing in hidden fields to store them on the querystring, I guess that when you click on the "next page" you include everything you need to save in the querystring, right? so that piece of query string gets appended in each and every link that performns some kind of action...
I'm not sure, what are the advantages and disadvantages of using the querystring instead of hidden inputs???
I use different strategies depending on the character of the actual data. Things that are preferences, like default page size, I keep in a Preferences object (table) that is associated with the current logged in user and retrieve from there when needed.
Persistent settings associated with the current logon, like filter settings for a page, are stored in the user's session. Generally these are things that if a user sets them in the current session they should remain sticky. I think filter settings and visibility are like this. If I filter a list, navigate away from it to drill down into a particular item, then come back to the list, I want my filter settings to be reapplied -- so I make it part of the session.
Context-dependent settings -- like the current sort column or page number, are controlled using query parameters. Paging and sort controls (links) are built with the appropriate query parameters to "do the right thing" when clicked and pass any necessary query parameters to maintain or update the current context of the control. Using the query parameters allows you to use an HTTP GET, which is bookmarkable, rather than a POST. Using hidden form parameters makes it much harder for the user to save or enter a URL that takes them directly where they want to go. This is probably more useful for sorting than it is for paging, but the principle applies equally.