none
Problems with Custom Field Type list view rendering

    Question

  • I'm upgrading an existing 2010 Custom Field Type to work with 2013. Where possible I'm attempting to re-use code from the 2010 version, to avoid duplicate work.

    The main problem I'm coming across appears to be a couple of either misunderstandings or bugs with the List View rendering in 2013:

    XSL

    The existing XSL stylesheet (from 2010) appears to be entirely ignored (both header and Text_body modes). When I manually move it from the 14 folder to 15 it's processed (I know this because an error is thrown if it's invalid), but still not used.

    I've attempted to use this with both CAMLRendering set to TRUE and FALSE.

    CAML

    When using CAMLRendering TRUE, the DisplayPattern for the body is used in most instances, but appears to be ignored when viewing anything after the first page.

    I've confirmed this by viewing the inplview.aspx calls: On the first page the response array contains the CAML-output values as expected, but on the second they're empty strings.

    General info

    • The actual field's data is empty, as the values are generated b the CAML/XSL.
    • The CFT is an actual working product on both 2007 and 2010, using CAML and XSL respectively.
    • Using SPField.JSLink isn't currently an option, due to internal constraints.

    Are there any workarounds to these problems? Are these known issues/bugs?

    Friday, December 07, 2012 10:55 AM

Answers

  • Given the lack of response, I'm guessing this is a case of the Custom Field Type rendering not being backwards compatible again. :/ Oh well.
    • Marked as answer by Stuart Pegg Tuesday, December 11, 2012 9:39 AM
    • Edited by Stuart Pegg Tuesday, December 11, 2012 2:22 PM
    Tuesday, December 11, 2012 9:38 AM

All replies

  • The CAML issue with paging appears to be related to the SPField.JSLink being defined:

    When it is defined, the CAML output is correct  (but HTML encoded by default, e.g. '<' becomes '&lt;').

    When it isn't defined, only the first page receives the CAML output (unencoded).


    • Edited by Stuart Pegg Thursday, December 13, 2012 5:17 PM
    Monday, December 10, 2012 4:00 PM
  • Given the lack of response, I'm guessing this is a case of the Custom Field Type rendering not being backwards compatible again. :/ Oh well.
    • Marked as answer by Stuart Pegg Tuesday, December 11, 2012 9:39 AM
    • Edited by Stuart Pegg Tuesday, December 11, 2012 2:22 PM
    Tuesday, December 11, 2012 9:38 AM
  • See if this enables rendering of your xsl in 2013

    1. Edit the page your web part is on (i.e. AllItems.aspx)
    2. Edit the web part for your list
    3. Under Miscellaneous section select "Server Render" and click Apply
    Thursday, December 13, 2012 5:13 PM
  • Web part? Do you mean all the List View Web Parts the Custom Field Type is rendered on? If so, I'm afraid that isn't reasonably possible: The CFT is sold as third party software.
    Thursday, December 13, 2012 5:16 PM
  • I have the same experience.  Did you ever find a workable solution, or did you have to bite the bullet and re-build it as a 2013 solution?
    Wednesday, May 08, 2013 8:22 PM
  • We had to use the new JSLink method, which is not without its problems.

    3 different methods for 3 different versions... SP2016 will probably just quietly drop support for CFTs altogether.

    Thursday, May 09, 2013 8:09 AM