SharePoint Publishing Site Map Providers and Navigation

本文介绍如何通过代码重复SharePoint 2010发布站点及其子站点的导航设置,并将其打包到特性代码中。讨论了使用PortalSiteMapProvider进行全局及当前导航配置的方法,以及如何实现自定义导航概念。

PublishingWeb Class

http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.publishing.publishingweb(v=office.14).aspx

 

Configuring the navigation of SharePoint 2010 publishing sites and subsites can be a bit confusing, also when configuring the navigation from code or from your web templates (or even old school site definitions). Add to that the UI that changes based on which settings you chose combined with what site or subsite context you're currently in. Plus the quite large number of site map providers defined in the web.config when using thePortalSiteMapProvider from code.

This post is about how the UI settings can be repeated in your site provisioning code, that is: first configure the navigation settings in your prototype to make it work according to yournavigation concept, then package the settings into feature code.

The PortalSiteMapProvider works in combination with the PublishingWeb navigation settings, and of course with the top and current navigation controls used to render the navigation as HTML. The latter needs to look at the publishing web'sPortalNavigation settings when querying the portal site map provider for the CurrentNode or when getting a set of navigation nodes to render. The navigation controls' code use the PortalSiteMapProvider properties IncludeSubSites, IncludePages, IncludeAuthoredLinks and IncludeHeadings to set the filtering applied to GetChildNodes when rendering nodes. These filter properties are typically set to IncludeOption.PerWeb to reflect the navigation settings of the current site or subsite.

The navigation settings UI tries to show the effects of your navigation settings (upper half) byrendering a preview of what nodes GetChildNodes would return for the *current* site (lower half) from the applicable site map provider. The PortalSiteMapProvider exposes several of the providers defined in web.config as static properties, but only two of them are typically used: CombinedNavSiteMapProvider and CurrentNavSiteMapProvider. The former is what feeds the top navigation, the latter feeds the current (left, local) navigation.


Note that when inheriting global navigation, the UI won't show the global navigation container as it only supports configuring the navigation of the current site. The term "parent site" in the UI refers to the top-level site of the site-collection, which is not the direct parent of a subsite beyond level 1 children.


Configuring the navigation settings from your site provisioning feature is quite simple once you've got a working prototype of your navigation concept. Use the mapping shown in the above figure to program the configuration settings for both global navigation (InheritGlobal, GlobalIncludeSubSites, GlobalIncludePages) and current navigation (InheritCurrent, CurrentIncludeSubSites, CurrentIncludePages, ShowSiblings).

The only little pitfall is for "Display the current site, the navigation items below the current site, and the current site's siblings" which requires a combination of InheritCurrent = false and ShowSiblings = true. Use this setting to show the same local navigation for a section of your web-site and all its child sites. A typical example is for the Quality Management section (level 1 subsite) and its QMS areas (level 2 subsites) to have a shared navigation experience. The QMS section would not use ShowSiblings while all the child areas would have ShowSiblings turned on.

Implementing a custom navigation concept is as simple as writing your own navigation rendering controls, and inheriting the PortalSiteMapProvider to override the logic for CurrentNode and GetChildNodes to suit your needs by applying the applicable node filtering properties to control which nodes are returned and rendered in which context. I've also used this approach for reading the navigation items from a central SharePoint list to get common cross site-collection top-navigation.

I hope this helped you understand how to realize your navigation concept from code, and that you're not totally confused by all the available site map providers and how they are used anymore.
这个是完整源码 python实现 Django 【python毕业设计】基于Python的天气预报(天气预测分析)(Django+sklearn机器学习+selenium爬虫)可视化系统.zip 源码+论文+sql脚本 完整版 数据库是mysql 本研究旨在开发一个基于Python的天气预报可视化系统,该系统结合了Django框架、sklearn机器学习库和Selenium爬虫技术,实现对天气数据的收集、分析和可视化。首先,我们使用Selenium爬虫技术从多个天气数据网站实时抓取气象数据,包括温度、湿度、气压、风速等多项指标。这些数据经过清洗和预处理后本研究旨在开发一个基于Python的天气预报可视化系统,该系统结合了Django框架、sklearn机器学习库和Selenium爬虫技术,实现对天气数据的收集、分析和可视化。首先,我们使用Selenium爬虫技术从多个天气数据网站实时抓取气象数据,包括温度、湿度、气压、风速等多项指标。这些数据经过清洗和预处理后,将其存储在后端数据库中,以供后续分析。 其次,采用s,将其存储在后端数据库中,以供后续分析。 其次,采用sklearn机器学习库构建预测模型,通过时间序列分析和回归方法,对未来天气情况进行预测。我们利用以往的数据训练模型,以提高预测的准确性。通过交叉验证和超参数优化等技术手段,我们优化了模型性能,确保其在实际应用中的有效性和可靠性。 最后,基于Django框架开发前端展示系统,实现天气预报的可视化。用户可以通过友好的界面查询实时天气信息和未来几天内的天气预测。系统还提供多种图表类型,包括折线图和柱状图,帮助用户直观理解天气变化趋势。 本研究的成果为天气预报领域提供了一种新的技术解决方案,不仅增强了数据获取和处理的效率,还提升了用户体验。未来,该系统能够扩展至其他气象相关的应用场景,为大众提供更加准确和及时的气象服务。
<think>我们正在解决OnnxStableDiffusionPipeline使用中出现的'providers and provider_options should be the same length'错误。 这个错误通常发生在使用ONNX Runtime时,当我们传入的`providers`和`provider_options`参数长度不一致时。 分析: - `providers`:指定要使用的执行提供者(如'CUDAExecutionProvider', 'CPUExecutionProvider'等)的列表。 - `provider_options`:是一个字典列表,每个字典对应一个执行提供者的配置选项。注意,每个提供者对应一个字典,因此`provider_options`的长度必须与`providers`的长度相同。 错误原因: 当我们使用`OnnxStableDiffusionPipeline`时,如果在初始化时传递了`provider_options`参数,但没有确保其长度与`providers`参数的长度相同,就会触发此错误。 解决方案: 1. 检查`providers`和`provider_options`的长度是否一致。 2. 如果只使用一个执行提供者,那么`provider_options`应该是一个包含一个字典的列表(即使只有一个提供者)。 3. 如果不需要为某个提供者指定选项,可以传递一个空字典。 示例: 假设我们想使用CUDA执行提供者,并为其指定一些选项(例如`arena_extend_strategy`),同时我们也希望保留CPU作为备用。那么我们应该这样写: ```python providers = [ 'CUDAExecutionProvider', 'CPUExecutionProvider' ] provider_options = [ {"arena_extend_strategy": "kSameAsRequested"}, # 对应CUDAExecutionProvider {} # 对应CPUExecutionProvider,没有额外选项则用空字典 ] ``` 然后,在创建管道时传入: ```python pipe = OnnxStableDiffusionPipeline.from_pretrained( model_path, providers=providers, provider_options=provider_options ) ``` 注意:如果我们没有指定`provider_options`,则默认会为每个提供者使用空选项。但是如果我们显式提供了`provider_options`,就必须确保其长度与`providers`相同。 如果不需要任何特殊的提供者选项,可以完全不传递`provider_options`参数,或者传递一个长度与`providers`相同的空字典列表。 常见错误场景: 1. 只传递了一个提供者,但`provider_options`却是一个空列表(长度为0)或者多个选项的列表。 2. 传递了多个提供者,但`provider_options`列表长度与提供者数量不匹配。 因此,请检查代码中这两个参数的长度是否匹配。 另外,如果我们使用的是`ORTStableDiffusionPipeline`(来自`optimum.onnxruntime`),那么传递方式也是类似的。 如果问题仍然存在,我们可以尝试不传递`provider_options`,让系统使用默认设置(即每个提供者使用空选项)。例如: ```python pipe = OnnxStableDiffusionPipeline.from_pretrained( model_path, providers=['CUDAExecutionProvider', 'CPUExecutionProvider'] ) ``` 这样就不会出现长度不一致的问题。 总结步骤: 1. 确认`providers`列表和`provider_options`列表的长度相同。 2. 每个提供者对应`provider_options`中的一个字典(即使为空字典)。 3. 如果不确定选项,可以不传递`provider_options`参数。 希望这些步骤能够解决您的问题。 相关问题: 1. 如何为ONNX Runtime配置多个执行提供者? 2. OnnxStableDiffusionPipeline 中 providers 参数有哪些可选值? 3. 如何优化ONNX模型在GPU上的推理性能? 4. 如何查看ONNX Runtime当前使用的执行提供者? 5. 在ONNX Runtime中如何设置CUDA执行提供者的选项? </think> ### 解决 OnnxStableDiffusionPipeline "providers and provider_options should be the same length" 错误 这个错误发生在使用 ONNX Runtime 时,`providers` 和 `provider_options` 参数长度不一致导致的。以下是详细解决方案: #### 错误原因分析 1. **参数长度不匹配**: - `providers` 参数指定执行提供者列表(如 `['CUDAExecutionProvider', 'CPUExecutionProvider']`) - `provider_options` 必须是对应每个提供者的配置字典列表 - 两者长度必须严格相等,否则触发此错误 2. **配置格式错误**: - 单个提供者时仍需用列表包裹配置 - 缺省配置需显式使用空字典 `{}` 占位 #### 解决方案步骤 1. **基本修正方法**: ```python # 错误示例 ❌ pipe = OnnxStableDiffusionPipeline.from_pretrained( model_path, providers=["CUDAExecutionProvider"], provider_options={"arena_extend_strategy": "kSameAsRequested"} # 字典不是列表 ) # 正确示例 ✅ pipe = OnnxStableDiffusionPipeline.from_pretrained( model_path, providers=["CUDAExecutionProvider"], provider_options=[{"arena_extend_strategy": "kSameAsRequested"}] # 使用列表包裹 ) ``` 2. **多提供者配置**: ```python # 多个提供者时需长度匹配 pipe = OnnxStableDiffusionPipeline.from_pretrained( model_path, providers=[ "CUDAExecutionProvider", "CPUExecutionProvider" # 后备提供者 ], provider_options=[ {"arena_extend_strategy": "kSameAsRequested"}, # CUDA配置 {} # CPU使用默认配置(空字典占位) ] ) ``` 3. **简化配置方法**: ```python # 不需要特殊配置时省略 provider_options pipe = OnnxStableDiffusionPipeline.from_pretrained( model_path, providers=["CUDAExecutionProvider", "CPUExecutionProvider"] ) # 等效于 provider_options=[{}, {}] ``` 4. **验证配置长度**: ```python providers = ["CUDAExecutionProvider", "CPUExecutionProvider"] provider_options = [{"device_id": 0}, {}] # 每个提供者对应一个配置项 assert len(providers) == len(provider_options), \ "providers 和 provider_options 长度必须相同" ``` #### 常见配置示例 | 使用场景 | providers | provider_options | |----------|-----------|------------------| | 单GPU加速 | `["CUDAExecutionProvider"]` | `[{}]` | | 多GPU分配 | `["CUDAExecutionProvider"]` | `[{"device_id": 1}]` | | GPU+CPU后备 | `["CUDAExecutionProvider", "CPUExecutionProvider"]` | `[{}, {}]` | | TensorRT加速 | `["TensorrtExecutionProvider"]` | `[{"trt_fp16_enable": True}]` | #### 高级调试技巧 ```python import onnxruntime as ort # 打印可用提供者 print("可用提供者:", ort.get_available_providers()) # 创建SessionOptions验证配置 so = ort.SessionOptions() so.graph_optimization_level = ort.GraphOptimizationLevel.ORT_ENABLE_ALL session = ort.InferenceSession("model.onnx", so, providers=["CUDAExecutionProvider"], provider_options=[{}]) # 提前验证配置 ``` > **关键提示**:当使用多个提供者时,ONNX Runtime 会按列表顺序尝试初始化,第一个可用的提供者将被使用[^1]。 #### 相关问题 1. 如何查看 ONNX Runtime 当前使用的执行提供者? 2. ONNX 模型如何优化 GPU 内存使用? 3. TensorRT 提供者与 CUDA 提供者有何性能差异? 4. 多 GPU 环境下如何指定设备 ID? 5. 如何解决 ONNX 模型加载时的 shape 推断错误?
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值