2024年10月21日
1、分页API接口现已支持（infinite_paging_api）请求。当监听器自动触发分页请求时，系统会自动解析无限数据包，并构建标准的分页方法以获取当前分页数据。需要注意的是，由于请求的复杂性，服务端的分页接口数据返回将根据不同场景进行自定义处理。整个监听器场景，自动化部署仅是针对前端处理。
2、通过使用xc_template_infinite_page_html模板生成的前端分页滚动加载组件，我们新增了一个自定义属性，即场景的标识名称（也可以理解为页面标识）。在现有的前端触发器中，这个标识名称会被提取到infinite对象数组中，并传递到服务端进行响应处理。服务端将根据这个标识名称来判断请求的来源，从而执行相应的分页请求数据填充操作。
3、服务端分页接口触发器请求现已支持【鉴定师订单列表：identify_expert_order_list】的数据返回处理。当收到该场景的请求时，系统将通过xc_identify_expert_identify_order_list_consult方法获取相应页码的订单数据。如果数据获取失败，系统会返回相应的错误提示；如果数据获取成功，系统将遍历数据并将其赋值到HTML中进行展示。
4、为了优化鉴定师订单的分页方法，将第一个参数从user_id更改为author_id。这是因为分页请求可能由管理员发起以查看鉴定师的订单。如果使用user_id作为参数，传递的用户UID会被内置的xc_is_login覆盖，导致返回的并非指定用户的鉴定订单，而是当前用户的鉴定订单。请注意，函数内部相关的用户参数已经进行了相应的修正处理。
5、模板组件方法：xc_template_infinite_page_html 新增了一个第三个可选变量 author_id。在某些场景下，需要读取指定用户的 UID 来获取分页数据。例如，查看审核日记、用户的鉴定申请记录或淘货的订单交易记录。这些场景都需要传递相应的用户 UID（而非当前用户）以便返回指定的参数。在这些情况下，提取页面的 UID 是完成订单数据源处理的关键步骤。
6、分页模板组件的方法得到了进一步优化，现在仅保留两个变量。第一个变量是key，用于标识场景；第二个变量是infinite，这是一个数组，默认情况下为空。如果不需要传递特殊参数，可以选择将其置空。举个例子：如果我的组件方法需要使用author_id（作者）这个参数，那么可以通过infinite['author_id']来传递参数，这样参数会自动接入到自定义属性中。再比如，在分页场景中需要使用cat（藏品分类）参数，也可以通过infinite['cat']来传递参数。
7、监听器升级优化，当onPageBeforeInit监听进入页面后，如果页面包含元素【.page-content.' + page_name + '_content.infinite_loading】则会触发ajax分页加载的监听。这里有个重要调整，如果page_content.attr('page')元素返回的数字是0，则会主动执行一个动作【page_content.trigger('infinite');】。注：意思是，检查初始页码是否为0，如果是，则主动请求数据。并执行原有的填充机制。换句话就是页面可以选择不提前填充内容，通过内置方法来进行页面初始化填充。
8、如果首页的数据需要通过监听器自动填充，那么在执行触发动作时，应提前使用page_list.empty();方法清空列表容器的所有子元素和文本内容。这样可以避免在插入分页数据后，原有的初始化提示信息（例如：“暂没有相关鉴定订单”）仍然保留在页面中，从而确保页面显示的内容是最新的和相关的。
9、页面标准化处理：目前在【page-content】后面新增了一个通用类名：xc_app。通过使用page-content.xc_app的选择器，可以有效判断页面是否归属于宫论APP。这一元素选择器极其重要，未来所有的页面位置检测和判断将依赖于这个类名组合来实现。对于移动端的页面开发，未来都必须强制将这个类名写入其中，以确保一致性和功能的正确性。
10、除了页面需要通过监听器来执行下拉滚动组件的数据加载填充外，还需要对应的菜单切换事件来完成指定分类的下拉滚动事件的处理。考虑菜单切换的场景也很多，因此单独封装一个前端事件来xc_hook_subnavbar()动态处理数据类型切换。该方法将结合分页组件，实现页面菜单切换，组件也会自动进行参数切换。
11、在进行页面交互时，xc_hook_subnavbar钩子需要提供三个关键变量，以确保功能顺利实现。首先是sort，这个变量用于状态分类，在从A菜单切换到B菜单时，通过sort标识可以实现数据的动态填充和更新。其次是key，该变量主要用作场景标识，通常是页面的唯一标识符。通过key，系统能够识别当前的数据请求来源，从而准确提供相应的数据支持。最后是this，这是一个上下文对象。处理菜单内部事件时，使用this可以便捷地操作和管理当前对象的属性和方法，确保功能逻辑的连贯性和一致性。
12、xc_hook_subnavbar：在进行菜单数据填充之前，该钩子会执行一系列交互操作。首先，会创建一个作用域变量【page_content】，后续所有的页面交互都会使用这个变量作为选择器进行操作。接下来，系统会检查名为.page-content.' + key + '_content'的元素是否存在，如果不存在，则会立即返回一个错误信息【非法请求】。然后，通过animate函数将导航栏的滚动位置重置为顶部，这一操作在菜单切换时尤为必要，以便刷新页面数据。最后，使用obj为当前选中的菜单项添加选中样式，同时确保移除其他菜单项的选中样式。

2024年10月20日
1、新增的模板组件脚本文件库【/global/publish/template.php】旨在简化组件的管理和使用。当项目中涉及到组件的调用时，只需通过require_once加载这个文件，即可实现自动加载所有的组件脚本库，例如：publish_report.php和publish_video.php等。未来扩展的新模板组件也将通过这个统一的脚本库集成进来，大大提升了系统的维护性和管理效率，使得组件调用变得更加方便快捷。
2、模板引擎解析脚本库新增了一个函数方法【xc_template_infinite_page_html】，用于处理分页下拉滚动加载的模板组件。这个方法需要传递两个变量。首先是分页的页面标识参数，这是一个唯一属性，对应后台配置的具体场景，用来防止监听器的错误重复注册。其次是html变量，即容器内的初始化展示内容。这可以是一段xc_empty的提示信息，也可以是已经封装好的li列表内容，具体的内容形式取决于前端的构造方式。
3、在使用模版引擎构造滚动下拉组件的过程中，首先会调用xc_is_config方法，检查验证配置xc_template_infinite_page中是否包含特定的页面标识场景的key。如果该key存在，那么将开始构建设计，并返回生成的HTML内容。这种直接返回HTML的做法是为了方便将内容输出到页面中。如果所需的key不存在，流程则会被跳过，函数会直接返回false，而不产生任何输出或数组结果。这种设计旨在提高页面渲染的效率和灵活性。
4、在修复页面返回功能时，我们发现了一个错误：页面返回时出现了“Uncaught ReferenceError: page_name is not defined”的报错。这种错误导致页面的后退动作异常，无响应的现象第一次发生后，用户很难再进行正常的页面返回尝试，第二次尝试返回时页面直接关闭，所有打开的页面都消失。经过深入分析，问题的根源是page_name这个变量被let声明，因此它的作用域受到限制，导致无法在全局范围内访问。为了彻底解决这个问题，已经将page_name变量移出局部作用域限制，并改为使用全局变量配置，使页面的后退行为恢复正常，避免了异常监听错误的出现。
5、通过模板引擎构造的下拉滚动器功能已经完成封装，这里提供的输出CSS类名结构如下。首先，我们有三个主要的全局class类名。第一个是template_infinite_page，这是父级类名，用作组件的标识。所有元素的操作都是通过这一父级类名来进行的。接下来是第二个类名：$config['key']，通常用作页面标识，根据具体页面场景的不同，可以设定不同的样式和行为。最后一个是自定义的$config['class']，这是由后台进行设定的，可以根据实际应用需求进行调整和适配，以确保组件在各个场景中的正确显示和功能性。
6、模版引擎的自定义属性和正文输出部分：自定义属性主要包括三个方面。首先是page属性，表示当前的页数，默认值设置为1。其次是number属性，指的是每页返回的数据量，这个数量通常由后台场景进行配置，默认值为20。最后是sort属性，这是一个分类状态标识，与页面的菜单切换功能相关，如果页面有切换菜单的功能，这个属性就必须被指定；但如果是单一页面的下拉滚动加载，这个属性可以为空。正文的输出部分通过<div class='list'>" . $html . "</div>来处理，其中$html是可变内容，如果它为空，则通过函数xc_empty($config['info'])生成适当的错误提示信息。这种设计确保了在不同条件下页面内容的动态调整和有效显示。
7、我的鉴定列表（identify_expert_order_list）现在已经升级，通过xc_local_link引用模板引擎库脚本。这种方式使得在页面中能够灵活调用xc_template_infinite_page_html(key,key,html = '')方法，来实现分页滚动加载组件的部署。当用户在页面上进行滚动操作时，系统会自动读取该组件的配置信息，然后通过请求服务端的分页接口，动态加载并填充相应内容到组件中。
8、为了提高滚动监听器的性能，我们对其结构进行了优化。之前的实现方式是利用page-content设置自定义属性，并通过内部统一监听器来读取这些属性信息。然而，这种方法需要将整个页面容器都纳入监听范围，这在处理页面自定义时显得不够灵活。因此，我们决定进行调整。现在，通过xc_template_infinite_page_html方法部署的滚动加载容器，不再依赖原有的page-content页面属性来完成配置读取。取而代之的是，通过其自带的属性来实现相应的处理，使得配置更加灵活，提升了页面的自定义友好性。
9、onPageBeforeInit页面访问监听器的机制进行了一次重要改进。之前通过使用page_name作为父级类名来进行处理（分页滚动加载）的旧方法，现在已经被淘汰。新的方法是通过检测页面中是否存在分页组件来进行选择器的判断【即：('.page-content.' + page.name + '_content .template_infinite_page')】。此外，页面自定义属性的获取方式也发生了变化，不再从page-content中直接提取，而是改为通过具体组件的自定义属性来获取。这种更新不仅提高了页面加载的灵活性，也增强了对复杂页面结构的支持能力。
10、在鉴定师订单列表页面（identify_expert_order_list）中，系统现在利用分页接口函数【xc_identify_expert_identify_order_list_consult】来获取首次加载时的首页数据。如果该请求成功且有订单记录返回，系统会创建一个名为list_consult_html的变量，随后，通过for循环将所有订单记录逐条转换为li元素并添加到list_consult_html中。完成数据的处理后，将赋值的list_consult_html变量传递给分页组件，实现页面的初步加载与展示。如果请求失败并且未返回任何订单记录，则list_consult_html会被标记为false，以反映数据加载的状态。
11、考虑到页面越来越多，组件扩展也越来越丰富。很多文档更新跟不上进度，页面交互动作写入出现重复问题。对于一些特定的页面结构设计，文档中单独列出一个示例文件夹。比如视频组件的调用方法，单独命名一个video.php，里面将会详细演示这个组件的调用使用方法。避免时间久了，忘记页面引入使用方法。造成阅读困难，甚至重写的问题。
12、在对监听器的自动分页递增动作进行优化时，原先的做法是通过读取content容器的page属性，将其值加1后重新写入，以确保页面标记始终处于有效状态。然而，在新版本的方法中，由于放弃了通过page-content作为父级类名的策略，原有方法失效。新的实现不仅更新和读取组件的页数，且引入了parseInt方法，将页数转换为整数后再进行累加，以防止可能出现的错误字符干扰，从而提升操作的准确性和稳定性。

2024年10月18日
1、在实现标准的通用ajax分页加载填充事件时，需要为加载li内容处理指定一个容器类名。这一类名的固定标识为【page_list】，书写格式规定为（page.name + '_list'），其中前者为动态页面标识符，后者则表示为列表的含义。不同页面的容器可以有各自独特的风格设置，支持根据子类进行个性化设定。通过场景标识解析，可以灵活应用不同的CSS样式，确保页面显示效果与其特性需求一致。
2、在page_content中新增了一个名为type的第四个属性，这是一个服务端API接口标识参数。由于封装的需要，对分页接口请求进行type表示处理显得尤为重要。例如，当type被设定为review_identify_expert_api时，系统在执行ajax填充请求时将自动识别并响应此type，从而执行相应的业务逻辑处理。通过在不同的场景下设定不同的type值，能够有效地实现接口业务的分类和优化处理，提高系统的灵活性和响应效率。
3、在通过onPageBeforeInit监听器来触发分页内容的加载时，提交到服务端的请求参数采用对象数组结构进行处理。为防止内存溢出，初始化变量定义为【infinite：作用域变量】。目前，该请求参数具备三个固定的键值：首先是“type”，用于标识具体的场景；其次是“page”，代表页数，默认为1；最后是“sort”，则用于指定分页类型，例如可以传递参数来仅返回已退款的订单或仅返回已通过审核的鉴定师名单等。除了这三个基础值外，还可以根据具体应用场景，动态提取并附加相应的属性值，然后对其进行封装再提交请求。通过这样灵活的参数设计，确保系统在满足多样数据请求场景的同时，维持高效的内存使用。
4、宫论的统一分页接口请求（paging.php）现已增强功能，支持监听器的分页请求功能（标识为：infinite_paging_api）。当监听器成功完成对infinite数组的对象封装时，会在页面的list容器中通过after方法插入一个loading_post动画，然后触发ajax请求以访问分页接口，此时会携带infinite数组一起发送。分页接口在接收到API请求后，首先会对请求的合法性进行验证，若验证通过，则提取infinite数组参数，并进行相应的业务处理。
5、为了优化分页请求的返回数据量，针对不同的场景需求进行调整，某些场景可能需要返回更多的数据内容，而某些场景则需要较少的数据量。为确保这种多样化要求的兼容性，采用了监听器自动化部署滚动加载器的新技术。通过此自动化系统，允许在容器内部设定一个自定义属性：“number”。这个属性的默认值被设置为20。若需要调整返回内容的数量，可以根据具体需求对这个数字进行修改。此属性会被封装成infinite['number']，并通过分页接口传递，实现了灵活的内容加载和用户体验优化。
6、监听器在自动触发分页请求（infinite_paging_api）后，首先进行接口的安全验证。完成验证后，它会从请求的post对象中提取出infinite数组，并对该数组中的值进行基本处理。具体来说，首先处理的是infinite['page']，即请求分页的页码。如果该值为空或不存在，则默认重置为1。接下来是每页设定的内容数量，即number参数。如果number为空或不存在，则默认设定为20。最后，通过设定offset来计算偏移量，具体公式为(infinite[ ′ page ′ ]，即请求分页的页码。如果该值为空或不存在，则默认重置为1。接下来是每页设定的内容数量，即number参数。如果number为空或不存在，则默认设定为20。最后，通过设定offset来计算偏移量，具体公式为(page - 1) * $number，从而获取到正确的页码内容。
7、为了实现前端页面的自动化滚动填充功能，通常需要设置多个复杂的容器参数。然而，为了简化这一过程并减少操作步骤，决定采用模块化设计处理方案。通过使用宫论内置的模板引擎，构建一个页面方法来完成容器组件的生成。这样的方法只需要传递一个场景名称，就能完成整个模块的生成。这不仅大大简化了部署工作，还使得后期的维护更加轻松，无需对每个页面进行单独维护，只需专注于模板方法的优化和调整即可。
8、在后台发布设置中，新增了一个名为【xc_template_infinite_paging_config】的配置组，专门用于模版引擎中的分页加载监听器配置。此配置器需要传递以下几个关键参数：首先是name参数，用于提供来源说明和详细文字介绍，以便用户理解该配置的作用。其次是key参数，这是一个为配置项提供唯一标识的标识符，设置后应保持不变，通常采用页面标识名称以确保唯一性。然后是class参数，负责定义样式，以便进行样式适配，确保页面呈现一致性。此外，number参数设定了每页加载的条目数量，默认为2，固定不变，便于保持统一的加载体验。最后是sort参数，其作为分页标识名称，主要用于指定需要状态的分页情况，若无特别需求则可以留空。
9、在xc_template_infinite_page的配置中，特别增加了两个新的字段，以提升其灵活性与用户体验：首先是“header_html”字段，它是一个大文本输入框，当你需要通过ajax加载一个自定义的HTML区域时，可以在此输入具体内容。这不仅支持HTML代码，还允许使用短代码，为用户在开发和设计上提供了更大的自由度。其次是“info”字段，用于显示提示内容。当系统需要告知用户某些信息，比如“没有更多鉴定订单”或“没有更多收藏记录”时，可以在这里自定义相应的提示或错误信息。这些字段都是作为扩展选项添加的，因此可以根据实际的使用场景选择是否进行配置，从而确保页面在加载和提示时的个性化需求都能得到满足。
10、新增第一个模版引擎[分页滚动加载]场景：【identify_expert_order_list：鉴定师的订单页面】。此场景的参数设定如下：自定义样式(identify_expert)被用于指定页面的样式布局，以确保页面显示符合预期。每页加载的订单条目数被设定为20，以便于用户在滚动时能够流畅查看订单详细信息。默认状态标识为0，这意味着在没有特别筛选条件的情况下，页面将返回所有订单，因为该页面支持菜单分页加载，因此默认设定为显示所有订单。加载更多内容时，若无更多订单需要显示，则页面将提示“没有更多鉴定记录”，以明确告知用户当前已浏览完所有可用记录。
11、新增的模板引擎配置文件【configure/template.php】中预设了图标为fa-opencart。在宫论项目中，模板引擎的概念已经被引入，并通过封装不同的组件实现了一键化的页面部署。然而，由于不同组件的配置选项各异，使得维护过程复杂且繁琐。为了解决这个问题，特别设定了一个独立的配置页面，用于存储和管理这些参数信息，从而简化维护流程，提高整体项目的可管理性。
12、以下配置字段已从其他地方迁移至【模版引擎配置页】：1. 模版引擎的[分页滚动加载]配置。2. 文本框表单配置字段：xc_publish_textarea_config。3. 图片上传组件配置：xc_publish_component_image。4. 表单内容填写组件配置：xc_publish_component_textarea。5. 视频上传组件配置：xc_publish_component_video。6. 藏品分类内容组件配置：xc_publish_component_category。7. 视频上传的相关配置：xc_upload_video_config。8. 图片上传的相关配置：xc_upload_image_config。这些字段都是为了优化模块的灵活性而封装的模版组件配置，通过将它们集中到一个配置页，可以更方便地进行管理和维护。此外，所有后续的模版组件也将整合封装到template.php文件中

最低多少钱？最低多少钱？

测试看看最低多少钱？

内容测试出