如果 struts/custom 标签在 javascript 方法中,它们何时会被解析

When do the struts/custom tags get resolved if they are inside javascript method

我遇到了一个很奇怪的问题。我有一个 jsp 页面,其中有一个 javascript 方法。此方法包含大量 Struts 和自定义标记。此方法迭代几个列表,然后动态创建行和列并将它们添加到 table.
此方法还会在那些新添加的行和列上创建一些指向其他 javascript 方法的链接。

现在的问题是这个方法是在文档准备好时调用的,它需要很多时间,页面需要几分钟才能完全呈现。 奇怪的是,即使我不调用此方法,页面也会花费很多时间。但是如果我在删除其中的代码后调用它,那么页面呈现得非常快。

所以我无法理解这些标记何时从服务器解析 - 在页面加载时或在服务器发送响应之前?

为什么即使我不调用此方法,此方法也会使我的页面变慢?

解决这个问题的标准方法是什么?

添加示例代码进行检查:

<s:set var="indexCount" value="0" />
                    <logic:iterator value="#someParentList" var="company" status="statusL">

                        <logic:iterator value="#childLIst" var="employee" status="statusB" >    
                            empBalHtml += '<tr>';
                            empBalHtml += '  <td class="flag" rowspan="2" >';
                            empBalHtml +=        getString(function(){/*!<s:checkbox name="enrolActivity.schBalempAllocationSave[%{#indexCount}].chk" />*/});     
                            empBalHtml +=        getString(function(){/*!<s:textfield value="%{#employee.billDate}"  fieldId="emp_ALLOCATION_SECTION" format="date" calendar="false" style="display:none" name="enrolActivity.schBalempAllocationSave[%{#indexCount}].schBalempTotalAppliedBillDate" />*/});
                            empBalHtml += '      <s:hidden name="enrolActivity.schBalempAllocationSave[%{#indexCount}].empIdKey" value="%{#employee.empIdKey}" ></s:hidden>';
                            empBalHtml += '      <s:hidden name="enrolActivity.schBalempAllocationSave[%{#indexCount}].primarySecondary" value="%{#employee.pmtStream}" ></s:hidden>';
                            empBalHtml += '      <s:hidden name="enrolActivity.schBalempAllocationSave[%{#indexCount}].employeeId" value="%{#employee.employeeId}" ></s:hidden>';
                            empBalHtml += '      <s:hidden name="enrolActivity.schBalempAllocationSave[%{#indexCount}].position" value="%{#indexCount + 1}" ></s:hidden>';
                            empBalHtml += '  </td>';
                            empBalHtml += '  <td rowspan="2" nowrap="nowrap">';
                            empBalHtml += '      <s:a id="empId-%{#statusB.index}"  fieldId="emp_ALLOCATION_SECTION" href="javascript:$.nav.urlForward(CTX_ROOT + \"/empDetails_load.do?empIDKey=%{#company.empIdKey}\")">${company.emp.empId}</s:a>';
                            empBalHtml += '      <s:if test="enrolActivityFlags.secondaryPresent" >&nbsp;(<s:label name="enrolActivity.empBalances[%{#indexCount}].pmtStream" value="%{#employee.pmtStream}"  fieldId="emp_ALLOCATION_SECTION"/>) </s:if>';
                            empBalHtml += '  </td>';

                            empBalHtml += '  <td class="numeric">';
                            empBalHtml +=        getString(function(){/*!<s:label value="0" format="currency" currencyCode="${enrolActivity.currency}" fieldId="emp_ALLOCATION_SECTION"/>*/});
                            empBalHtml += '  </td>';
                            empBalHtml += '</tr>';     

                            <s:set name="indexCount" value="%{#indexCount + 1}"/>
                         </logic:iterator>

                    </logic:iterator>

                    $("#someRow").after(empBalHtml); 

JSP 和(自定义)struts 标记在服务器端呈现,Javascript 在大多数 struts 环境中总是客户端(浏览器)。因此,您的浏览器可能很慢,因为您在服务器端生成大量 javascript 代码,而浏览器必须 运行。如果您始终调用此方法,则每次您的浏览器访问该页面时,它都会 运行 准备好文档。或者可能是因为太大,影响了传输时间。

示例:以下 JSP 和浏览器的 HTML 结果:

...
<script>
var myvar = "<s:text name='foo.bar'/>";    
</script>
...

浏览器的结果,浏览器中的 javascript 引擎必须 运行:

...
<script>
var myvar = "My Foo Bar translation";
</script>
...

以 Firefox 为例,"Inspector"(右键单击页面)并查找脚本选项卡或检查 DOM。

Why does this method make my page slow even if I don't call this method?

因为每个Struts2标签都被翻译成HTML(例如<s:select><s:textarea>)或纯文本(例如<s:property/><s:date/>) 页面发送到浏览器之前。

但是,如果您将这些标签注入 javascript 块,请记住设置 escapeJavascript="true" 否则您将面临中断页面加载的风险,并且容易受到 javascript 注入.

What is the standard way to tackle this problem?

> Pagination <

如果你有 100 万条记录,无论你通过 HTML、javascript 或其他方式附加它们,你只需要加载和渲染其中的 10 / 50 / 100,而不是一百万.