For the sake of development efficiency, we usually customize the built-in aspx forms such as the creation and editing of the Sharepoint list, but in the actual process, there will always be inexplicable errors, this may cause unlimited development delays.
First of all, as developers, we need to understand Microsoft's consistent style of action, that is, a mistake is often not your approach, but the system is not perfect.
Therefore, I have written down my experiences in SharePoint development over the years. In SPD, I often cannot change the data view too frequently, if you perform a non-demo operation on the data view, unexpected errors may occur, resulting in unlimited delays in your development time.
I have summarized these errors for the following reasons:
1. Change the "new" and "edit" modes of data frequently. When the data video you insert changes from the new form to the edit form, this will cause a huge disaster.
2. The data presentation mode is changed frequently. If you feel that the default display effect of a field is not moving, you can change it from "list form field" to "text box ", then, the change will cause a huge disaster.
By analyzingCodeTo discover the mysteries:
For example, when defining a data view of a new list, the system automatically generates the following definition in SPD:
<SharePoint: formfield runat = "server" id = "ff27 {$ POS}" ControlMode = "new" fieldname = "_ x7533 _ x8bf7 _ x5173 _ x95ed _"
_ Designer: bind = "{ddwrt: databind ('I', Concat ('ff27', $ POS), 'value', 'valuechanged ', 'id', ddwrt: escapedelims (string (@ ID), '@ _ x7533 _ x8bf7 _ x5173 _ x95ed _')} "/>
When 1 occurs, I will find that a property ControlMode in this field may be incorrect. When creating a form, we must keep the value equal to new, this value may conflict with our form when it is changed multiple times.
When 2 occurs, I will find that in the _ designer: bind attribute, In the ddwrt: databind method, Concat ('*******', $ POs, this part is incorrect,
This part should correspond to the ID property. If the ID is ***** {$ POS}, this part should be conct ("*****", $ POS }.
Therefore, when customizing data views, we need to develop an idea that SPD only provides us with tools to automatically generate code, rather than what Microsoft calls a omnipotent tool, which is full of bugs,
Do not trust the code automatically generated by Spd. You can check the automatic code generated by Spd and correct it to use this tool efficiently.
In fact, in Versions later than sharepont 2013, the WYSIWYG view mode is canceled. I think this may be the future mission of SPD. Since Automatic Generation of code is not good, let professionals write XSL code one line at a time, rather than professionals. You can use SharePoint as a feature.