I have a reasonable idea what updateCMSFields does - updates (ie adds/removes) fields from the CMS.
According to the comments in updateFrontEndFields() (line 175 of DataDecoratorObject.php) performs a similar method for front end forms.
But when and how is it used? I'm trying to find some real-word examples that demonstrate its usefulness...
Eg. Line 36 of [url=https://github.com/ajshort/silverstripe-addressable/blob/master/code/Geocodable.php]Geocodable.php[/url]. What is purpose of calling updateCMSFields() here? Having set a breakpoint on this method and debugging an instance using Addressable/Geocodable, it doesn't seem to hit this breakpoint?
updateFrontEndFields seems like it was a half baked implementation, all the modules I've seen refer to the front end differently so you'll find your mileage using that will vary. I guess the module is trying to conform to the DataObjectDecorator interface by including support for it. If you want to make your own custom signup form then in the front end you could use it like $fields = $member->getFrontEndFields() which'll pickup all the fields in extensions attached to Member.
The getFrontEndFields fields method is actually just a counterpart to the getCMSFields method - just without the tabbed interface and other CMS-centric things. Although it's not used out of the box I personally use it quite extensively when creating forms in the front end. The updateCMSFields and updateFrontEndFields methods are used so extensions can modify the CMS or front end form fields for editing an object. The reason I called one inside the other in this case is because they both do the same thing, and i didn't want to repeat the code.
@ ajshort, Thanks very much for your response Andrew.
So you use updateCMSFields/updateFrontEndFields as good practise...
So in this instance, you didn't want either Lat/Lng to be visible in the CMS or on Front End Forms? But why would you explicitly need to remove them, even though you're not adding them to the CMS/Front End forms at all?