This project is read-only.

Custom field types (gap in ams)?

Apr 8, 2014 at 5:47 PM
In my current project, we have custom field types which basically overrides the standard texbox and allows an autocomplete textbox, I wonder what would be the replacement on this case in the AMS world?

My custom field type uses server side logic, but I think I I can replace it with javascript code, that is not a problem, the problem is how to if possible to create a custom field type in AMS (if that makes sense)
Apr 23, 2014 at 12:12 PM
Custom field types are indeed proplematic. They were actually already problematic during SP2010 or SP2007 versions when we do major version upgrades.

In older versions we did not however have the opportunity to use client side rendering with the site columns. New approach would be to use the JSLink property in the Field object to define the client side rendering logic. This way you can override the default rendering logic for read only and for the edit experience, so that you can essentially provide similar end user experience as with the custom field types.

This client side rendering pattern is not that well documented in MSDN, but we should be getting updated demos out soon. I'll also put this one to the Office AMS back log, so that we could provide the reference implementations on how to replace or avoid custom field types in the new way of implementing needed customizations.
Marked as answer by vesaj on 5/19/2014 at 10:41 AM