自定义应用程序页面中的 SharePoint SPContext.List

发布于 2024-07-04 14:06:48 字数 397 浏览 6 评论 0原文

我有一个自定义 SharePoint 应用程序页面部署到 _layouts 文件夹。 它是自定义内容类型的自定义“新表单”。 在与此页面交互期间,我需要将一个项目添加到我的列表中。 当页面首次加载时,我可以使用 SPContext.Current.List 来查看我正在使用的当前列表。 但是,在我填写表单并且表单回发到自身并且 IsPostBack 为 true 后,SPContext.Current.List 为 null,因此我找不到需要添加内容的列表。

这是预期的吗?

我应该如何在回发过程中保留有关上下文列表的一些信息? 我是否应该使用列表的 guid 填充一些 asp:hidden 控件,然后在回发时将其拉回? 我想这看起来很安全。

FWIW,这是 MOSS 2007 标准版本。

I have a custom SharePoint application page deployed to the _layouts folder. It's a custom "new form" for a custom content type. During my interactions with this page, I will need to add an item to my list. When the page first loads, I can use SPContext.Current.List to see the current list I'm working with. But after I fill in my form and the form posts back onto itself and IsPostBack is true, then SPContext.Current.List is null so I can't find the list that I need to add my stuff into.

Is this expected?

How should I retain some info about my context list across the postback? Should I just populate some asp:hidden control with my list's guid and then just pull it back from that on the postback? That seems safe, I guess.

FWIW, this is the MOSS 2007 Standard version.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

永言不败 2024-07-11 14:06:48

一般来说,我会尝试复制产品组在添加我自己的功能时所采取的任何方法。 在这种情况下,他们通过列表定义本身添加自己的编辑/查看/添加页面。

我构建了一个解决方案,它也需要自己的自定义“新”表单,不幸的是,它不是开源的,但如果您有兴趣,可以下载它,它称为“标记链接”(SharePoint 社交书签),您可以在我的网站上找到一些链接博客。

为了给您一些提示和技巧,以下内容应该让您朝着正确的方向前进:

  1. 创建了一个新的列表定义。
  2. 创建了新的内容类型 在内容类型中,您可以定义自己的“FormTemplates”,它引用渲染模板,该模板确定在这些表单的“中间”位中显示的内容。
  3. 复制了标准渲染模板,但随后对其进行了更改
    需要。
  4. 将其全部包装在解决方案中并进行部署。

我的渲染模板实际上包含一个被覆盖的“保存”按钮,我在保存过程中完成了许多额外的工作。

无论如何,在我看来,这有点太多的工作,但我认为,它最符合产品开发人员所采用的标准方法。 如果您需要更多详细信息,请告诉我,我会看看是否可以整理一篇分步博客文章,但希望这能让您走上正确的方向。

Generally speaking I try and copy whatever approach the product group has taken when looking to add functionality of my own. In this case they add their own edit/view/add pages via the list definition itself.

I built a solution that also needed its own custom "New" form, not open source unfortunately, though if you are interested you can download it, its called "Tagged Links" (Social Bookmarking for SharePoint) and you can find some links on my blog.

To give you a few hints and tips, the following should set you off in the right direction:

  1. Created a new list definition.
  2. Created a new Content Type In the content type you can define your own "FormTemplates" that references a Rendering Template which determine what gets displayed in the "Middle" bit of those forms.
  3. Copied the standard Rendering Template, but then made the changes to it that I
    needed.
  4. Wrapped it all up in a solution, and deployed.

My Rendering Template actually included an overridden "Save" Button where I did a lot of the extra work I needed to do during the save.

Anyway, it is a little too much work in my opinion but, I think, it most closely matches the standard approach taken by the product developers. Let me know if you need more detail and I will see if I can put together a step-by-step blog post, but hopefully this gets you off on the right direction.

很糊涂小朋友 2024-07-11 14:06:48

如果您可以在 _Layouts 文件中执行一些在表单模板中无法执行的操作,我会感到惊讶。 您可以使用几乎相同的技术。

查看 SharePoint 使用 ListItems 和布局页面的方式(例如列表项上的“管理权限”),我可以看到它们通过查询字符串传递一些变量:
?obj={76113B3A-FABA-4389-BC85-4BB2CC5AB423},6,LISTITEM&List={76113B3A-FABA-4389-BC85-4BB2CC5AB423}

也许他们每次以编程方式使用这些值时都会夺回上下文。

I would be surprised if you could do something in a _Layouts file that you can't do in a forms template. You have pretty much the same technologies at your disposal.

Looking at the way SharePoint works with ListItems and Layouts pages (for example "Manage Permissions" on a list item), I can see that they pass some variables in via querystrings:
?obj={76113B3A-FABA-4389-BC85-4BB2CC5AB423},6,LISTITEM&List={76113B3A-FABA-4389-BC85-4BB2CC5AB423}

Perhaps they grab the context back each time programmatically using these values.

在巴黎塔顶看东京樱花 2024-07-11 14:06:48

我没有使用自定义的“新表单”,因此这可能不适用。 我向自定义内容类型添加了一个事件接收器,然后在 ItemAdded 或 ItemAdding 事件中执行自定义代码。 当事件添加到列表时,将触发此代码。 您可以使用事件接收器属性来访问父列表、Web 和站点。

I'm not using a custom "new form", so this might not apply. I added an event receiver to my custom content type and then do my custom code in the ItemAdded or ItemAdding events. This code fires when the event is added to a list. You can use the event receiver properties to get to the parent List, Web, and Site.

2024-07-11 14:06:48

我想我的问题在这里是“特殊的”,因为我使用的是自定义表单。 我选择使用自定义表单而不是自定义 FormTemplate 只是因为我正在做很多不太像 SharePoint 列表的事情(进行 ajax 调用以从第三方应用程序获取信息,然后生成一些基于ajax 结果,然后在回发时对该数据进行后续处理)。 我认为在通常的自定义渲染模板机制中尝试这个将是一场噩梦。

我也不认为我可以在列表定义本身中提供自定义表单声明,因为我有多个与此列表关联的内容类型,并且每个内容类型都有自己的自定义表单(幸运的是,其他类型要简单得多)。

实际上,我将列表 GUI 保留在隐藏字段中的简单方法是解决此特定问题的影响非常小的方法。 我主要担心的是,我不确定为什么当我在这里回发时 SPContext 就失去了所有用处,这让我觉得我做错了什么。

I'd like to think my issue is "special" here, since I am using a custom form. I chose to use a custom form rather than a custom FormTemplate simply because I'm doing a lot of stuff that's not very SharePoint list-like (making ajax calls to get info from a third-party app then generating some dynamic form elements based on that ajax result, then subsequent processing of that data on postback). I thought it'd be a nightmare to try this within the usual custom rendering template mechanism.

I also don't think I can supply the custom form declarations in the list definition itself, because I have multiple content types associated with this list, and each content type has its own custom form (the other type is thankfully much simpler).

Actually, my simple way of keeping the list guid in my hidden field was a very low impact way to address this specific problem. My main concern is that I'm not sure why the SPContext just loses all its usefulness when I postback here, which makes me think I'm doing something wrong.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文