开发者

Differences between a custom NewForm.aspx and EditForm.aspx in a SharePoint 2007 List

I'm working in a list with a custom NewForm.aspx and a custom EditForm.aspx, which I've called New.aspx and Edit.aspx. I'm far from a SharePoint expert, but it looks like the only differences between the two files are the miscellaneous ControlMode attributes set throughout the file.

ControlMode="New" for New.aspx and ControlMode="Edit" for Edit.aspx

As a test, I took the code from my New.aspx and copied it into my Edit.aspx and just changed the ControlMode attributes to 'Edit.' Everything seems to be working fine. So what I'd like to do is just use one file rather than a separate one for New and Edit. I'm not sure if this is possible, but the first step I took was to create an XSL variable:

<xsl:variable name="ControlMode" select="'Edit'" />

Then I can do something like this:

<xsl:choose>
  <xsl:when test="$ControlMode = 'New'">
    <SharePoint:AttachmentUpload 开发者_开发知识库runat="server" ControlMode="New"/>
    <SharePoint:ItemHiddenVersion runat="server" ControlMode="New"/>
  </xsl:when>
  <xsl:when test="$ControlMode = 'Edit'">
    <SharePoint:AttachmentUpload runat="server" ControlMode="Edit"/>
    <SharePoint:ItemHiddenVersion runat="server" ControlMode="Edit"/>
  </xsl:when>
</xsl:choose>

My form is still working fine at this point, but it's still two different files. So the question is, does anyone know a way I can populate the xsl:variable dynamically so that I can specify just one file for new and edit modes?

Thanks in advance!


I'm not sure if answering my own question is correct etiquette or not, but I found my answer... turns out to be much simpler than I thought.

As I was reading Brian's reply, it occurred to me that editing a post changes the query string. There's an ID specified of course. So I started looking for the best way to parse the query string. That's when I realized that this is already done for me in the ParameterBindings:

<ParameterBinding Name="ListItemId" Location="QueryString(ID)" DefaultValue="0"/>

The xsl:param tag was not specified however, so I added this to the top of my xsl:stylesheet:

<xsl:param name="ListItemId"></xsl:param>

Then, instead of using the ControlMode variable that I created in my original post, I can now test directly against the ListItemID:

<xsl:choose>
  <xsl:when test="$ListItemId = '0' or not($ListItemId)">
    <SharePoint:AttachmentUpload runat="server" ControlMode="New"/>
    <SharePoint:ItemHiddenVersion runat="server" ControlMode="New"/>
  </xsl:when>
  <xsl:otherwise>
    <SharePoint:AttachmentUpload runat="server" ControlMode="Edit"/>
    <SharePoint:ItemHiddenVersion runat="server" ControlMode="Edit"/>
  </xsl:otherwise>
</xsl:choose>

Basically, I'm just checking for a 0 value (the default specified in the ParameterBinding) and showing different controls.

I've been testing this for a bit this afternoon, and thus far it works brilliantly.


the built in sharepoint controls will attempt to function differently based on the control mode defined. Obviously if it is edit, then it will attempt to not only just render a control but populated that control with the current value. If the mode is new, it will simply render the control without a predefined value. There's a lot more to it but that's the high level overview.

If you are using custom new vs edit form I'd personally keep them seperate for the organizational purposes. An easy solution would be to use an XSL include after you have defined the variable inside each pages form.

0

上一篇:

下一篇:

精彩评论

暂无评论...
验证码 换一张
取 消

最新问答

问答排行榜