Velocity的中文指南(3)-整理

本文介绍了Velocity模板引擎的脚本元素。包括#foreach元素用于循环,可遍历列表、哈希表等;#include元素可导入本地文件,文件内容不渲染;#parse元素能导入包含VTL的本地文件并解析渲染,支持递归;#stop元素可停止模板引擎执行,常用于调试。

1.       循环

1.1.     Foreach 循环

 #foreach 元素允许进行循环,例如:

<ul>

#foreach( $product in $allProducts )

    <li>$product</li>

#end

</ul>

这个#foreach 循环将导致$allProducts 列表 (对象) 为查询所有的产品$products (目标)遍历一遍。每次经过循环,从$allProducts 取得的值将置于$product 变量之中。

$allProducts 变量的内容是一个矢量,一个哈希表或者数组。赋给$product 变量的值是一个Java 对象并且可以从一个类似的变量引用。例如,如果 $product 真是一个Java的产品类,其名称可以通过引用$product.Name 方法来检索(即: $Product.getName())。

 

我们假定 $allProducts 是一个哈希表。如果你想检索关键字的值或者在哈希表中的对象,你可以使用以下的代码:

 

<ul>

#foreach( $key in $allProducts.keySet() )

    <li>Key: $key -> Value: $allProducts.get($key)</li>

#end

</ul>

 

Velocity 提供一个更容易的方式或的循环计数,以便你可以做下面类似的工作:

<table>

#foreach( $customer in $customerList )

    <tr><td>$velocityCount</td><td>$customer.Name</td></tr>

#end

</table>

 

循环计数变量的缺省名称是$velocityCount,在velocity.properties 配置文件中标明。默认情况下,该变量从1开始计数,但是可以在velocity.properties 文件中设为从0或者1开始。 下面是velocity.properties 文件中循环变量设置一节:

# Default name of the loop counter

# variable reference.

directive.foreach.counter.name = velocityCount

 

# Default starting value of the loop

# counter variable reference.

directive.foreach.counter.initial.value = 1

 

2.       包含

#include 脚本元素允许模板设计人员包含(导入)本地文件, 这个文件将插入到#include 指令被定义的地方。文件的内容并不通过模板引擎来渲染。处于安全的原因,被包含的文件只可以放在TEMPLATE_ROOT下。

 

#include( "one.txt" )

 #include 指令引用的文件在双引号内。如果超过一个文件,其间用逗号隔开。

#include( "one.gif","two.txt","three.htm" )

 

被包含的文件并不是一定要用文件名来引用,事实上,最好的办法是使用变量而不是文件名。这在根据规则决定何时提交页面时,决定目标输出是很有用的。

#include( "greetings.txt", $seasonalstock )

 

 

3.       解析

 #parse 脚本元素允许页面设计员导入包含VTL的本地文件。 Velocity将解析和渲染指定的模板。

#parse( "me.vm" )

 

就象 #include 指令,#parse 可以使用变量而不是一个实在的模板文件。#parse 引用的模板文件必须包含的TEMPLATE_ROOT指定的目录之下。和 #include 指令不一样, #parse 只有一个参数。

VTL 模板templates can have #parse statements referring to templates that in turn have #parse statements. By default set to 10, the parse_directive.maxdepth line of the velocity.properties allows users to customize maximum number of #parse referrals that can occur from a single template. (Note: If the parse_directive.maxdepth property is absent from the velocity.properties file, Velocity will set this default to 10.) Recursion is permitted, for example, if the template dofoo.vm contains the following lines:

Count down.

#set( $count = 8 )

#parse( "parsefoo.vm" )

All done with dofoo.vm!

 

It would reference the template parsefoo.vm, which might contain the following VTL:

$count

#set( $count = $count - 1 )

#if( $count > 0 )

    #parse( "parsefoo.vm" )

#else

    All done with parsefoo.vm!

#end

 

After "Count down." is displayed, Velocity passes through parsefoo.vm, counting down from 8. When the count reaches 0, it will display the "All done with parsefoo.vm!" message. At this point, Velocity will return to dofoo.vm and output the "All done with dofoo.vm!" message.

 

4.       停止

 

 #stop 脚本允许模板设计员停止模板引擎的执行,并返回。这通常用作调试。

#stop

下载前必看:https://renmaiwang.cn/s/bvbfw Verilog设计_串并转换 / 移位寄存器实现了一种串并转换的功能,其核心原理在于移位寄存器的运用。 这里详细展示了串转并以及并转串两种不同的设计方案。 每一种转换模式都设有专属的使能信号,同时并行输出数据的格式提供了两种选择:最低有效位优先(lsb)和最高有效位优先(msb)。 串并转换技术主要应用于串行传输与并行传输这两种数据传输模式之间的相互转换,而移位寄存器是达成这一目标的常用工具,能够支持并行及串行的数据输入与输出操作。 这些移位寄存器通常被设定为“串行输入、并行输出”(SIPO)或“并行输入、串行输出”(PISO)两种工作模式。 在串行数据输出的过程中,构成数据和字符的码元会按照既定的时间顺序逐位进行传输。 相比之下,并行数据传输则是在同一时刻将固定数量(普遍为8位或16位等)的数据和字符码元同时发送至接收端。 数据输入通常采用串行格式进行。 一旦数据成功输入寄存器,它便可以在所有输出端同时被读取,或者选择逐位移出。 寄存器中的每个触发器均设计为边沿触发类型,并且所有触发器均以特定的时钟频率协同工作。 对于每一个输入位而言,它需要经过N个时钟周期才能最终在N个输出端呈现,从而完成并行输出。 值得注意的是,在串行加载数据期间,并行输出端的数据状态应保持稳定。 数据输入则采用并行格式。 在将数据写入寄存器的操作过程中,写/移位控制线必须暂时处于非工作状态;而一旦需要执行移位操作,控制线便会变为激活状态,并且寄存器会被锁定以保持当前状态。 只要时钟周期数不超过输入数据串的长度,数据输出端Q将按照预定的顺序逐位读出并行数据,并且必须明确区分最低有效位(LSB)和最高有效位(MSB)。
内容概要:本文档是PCI-SIG发布的工程变更通知(ECN),旨在为PCIe Base Specification 7.0中的组件测量与认证(CMA-SPDM)功能增加对后量子密码学(PQC)算法的支持。基于NIST发布的PQC标准(FIPS 203、204、205)以及NSA提出的CNSA 2.0安全套件要求,文档明确新设备必须强制支持ML-DSA-87(用于数字签名)和ML-KEM-1024(用于密钥封装)两种PQC算法,同时允许选择性支持传统算法(如RSA、ECC)或其他NIST批准的PQC参数集。变更不影响现有硬件或软件兼容性,但建议通过厂商特定配置机制灵活启用或禁用算法以应对未来安全演进。此外,文档指出PQC可能带来消息体积增大和性能延迟问题,并推荐使用CHUNK_CAP机制处理大数据传输及利用SPDM协议的“ResponseNotReady”机制缓解响应超时风险。; 适合人群:从事PCIe协议开发、安全芯片设计、固件开发及相关标准制定的技术人员,尤其是涉及国家安全或高安全性系统的产品开发者。; 使用场景及目标:①指导PCIe设备实现符合CNSA 2.0要求的后量子安全通信能力;②帮助开发人员理解如何在SPDM框架下集成PQC算法并处理性能与兼容性挑战;③为测试团队提供新增C&I测试需求的依据。; 阅读建议:此文档技术性强,需结合SPDM 1.4规范与NIST相关标准(FIPS 203/204/205)同步研读,重点关注第6.31.3至6.31.5节的具体算法要求与实现注释,便于在产品设计中提前规划密码模块升级路径。
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值