JSTL против JSP Scriptlets

Question

Я хочу, чтобы кто-то объяснил некоторые моменты в удивительном ответе BlausC в на этот вопрос .

Он сказал, что у скриптлетов есть некоторые недостатки:

1. Возможность повторного использования: вы не можете повторно использовать скриптлеты. Мой вопрос: как я могу повторно использовать код JSTL?

2. Заменимость: вы не можете сделать скриптлеты абстрактными. Что означает абстрактное и как JST может стать абстрактным?

3. OO: нельзя использовать наследование / композицию. Как я могу использовать ОО-парадигмы в JSTL?

4. Отладка: если скриптлет выбрасывает исключение на полпути, все, что вы получаете, это пустая страница.

5. Тестируемость: скриптлеты не могут быть проверены модулем. Что это значит, и как JSTL может быть модульно протестирован?

6. Ремонтопригодность: для каждого отдельного случая требуется больше времени для поддержки логики смешанного / загроможденного / дублированного кода. Что это значит?

Последнее, что он цитировал из рекомендации Oracle:

Скриплеты JSP не должны использоваться для написания бизнес-логики.

В шаблоне MVC я использую скриптлеты только на уровне представления. Что он имеет в виду здесь?

Answer 1

Вы, кажется, концентрируетесь только на части представления и управления потоком сценариев, как при использовании операторов if, for и switch и out.print() вещей.Вы, кажется, сравниваете скриптлеты 1: 1 с JSTL.Это не верно.Я говорил не только о части управления потоком (которая действительно должна быть заменена JSTL), но о написании необработанного кода Java в файлах JSP в целом.Т.е. сбор параметров запроса, проверка и преобразование значений, взаимодействие с базой данных и другими классами / методами Java и т. Д. Все, что вы обычно (косвенно) делаете в сервлете или фильтре.

Answer 2

Вы должны не иметь код скриптлета в JSP. Я бы порекомендовал 100% JSTL и нулевой код скрипта.

JSP должны быть чисто презентационными. Это скрытое преимущество написания JSP с использованием только JSTL, потому что они получают все свои динамические данные в другом месте. Позвольте сервисному уровню иметь бизнес-логику и определить, какие данные нужны JSP.

Это также отвечает на ваш вопрос о модульном тестировании. Вам не нужно проводить юнит-тестирование JSP; это были бы селеновые тесты пользовательского интерфейса. Если логика находится на уровне сервиса, очевидно, как вы ее тестируете.

JSP не должны наследоваться. Вы, конечно, можете составить их вместе, используя что-то вроде SiteMesh, но наследование не участвует в ваших JSP. Как только они наследуются от Servlet, цепочка должна быть прекращена.

Кроме того, это ложная альтернатива. Никто не должен требовать повторного использования, наследования или модульного тестирования. Но это не значит, что нет явного победителя: это JSTL. Никто не должен использовать скриптлеты в JSP, за исключением очень редких однострочников. Скриплеты умоляют о неприятностях.

В наши дни я предпочитаю Velocity как шаблонное решение для веб-интерфейса для Java, а не JSP. Просто мое мнение.

Answer 3

Я не могу говорить за BalusC, но в целом я полагаю, что он пришел к мысли, что такого рода вещи должны выполняться вашим обычным Java-кодом (на уровнях Controller и Model, если вы в целом разбираетесь в MVC) ).

1. Вы не можете буквально повторно использовать теги JSP на отдельном уровне, но вы можете повторно использовать классы, в которые они вызывают.

2. JSTL не может быть абстрактным, но обычный Java-код (который вы, возможно, можете вызвать из JSTL) может быть.

3. Опять же, вы не можете создавать объекты с пользой в jstl, но вы можете делать это во всех вызываемых классах.

4. JSTL сам по себе не является модульно-тестируемым. Но классы и методы, которые вы вызываете через него:

Answer 4

Я не вижу, что сценарии слишком плохи, особенно если вы следуете шаблону проектирования в нем, я много работаю над Spring MVC, в моем JSP я просто получаю данные модели в скриптах, и я показываю их пользователю, используя простой Java код в HTML, я чувствую, что это дает мне больше свободы, чем JSTL.

Answer 5

Это зависит от шаблона, который вы используете. Используя MVC ( spring, struts, ... ), вы должны избегать использования скриптлетов в JSP, поскольку они представляют представление, которое должно содержать чистые теги XHTML. JSTL - это декларативный язык, своего рода XML, а scriplet - нет.

В частности, я использовал JSTL в сочетании с AJAX через прототип для генерации RIA без необходимости реализации другого шаблона. Недавно я видел такой вид программирования с ExtJS и DWR . В моем случае я обнаружил, что необходимо объединить как JSTL, так и сценарии, всегда предпочитая JSTL, когда это возможно.

<!-- simple controller, each action is called by means of AJAX -->
<% String signExt="jpg"; %>
<% int r=0, iMaxRows=0, iMaxCols=0;%>
<c:choose>

    <c:when test="${param.action == 'get_chrequest_profile_table_by_family_and_date'}">
        <sql:query var="dataset">
            CALL GetProfilesView('<c:out value="${param.family_name}" />', '<c:out value="${param.reg_date}" />')
        </sql:query>

        <c:set var="strElements"><c:out value="${dataset.rowCount}" /></c:set> 
        <%  
        String strElements = pageContext.getAttribute("strElements").toString();
        int iElements = (int)Integer.valueOf(strElements).intValue(); 
        String to = "";
        %>

        <table class="tb_profiles" id="tb_profiles" iElements="<%=iElements%>"
               width="100%" frame=void border="0" cellPadding="0" cellSpacing="0" style="border-top: 3px solid gray; border-left: 1px solid gray">

            <%for(int i=1, j=0, col=0; i<100; i++){%>
            <tr>
                <%for(j=0; j<4; j++, col++){%>
                <c:set var="c" scope="page"><%=col%></c:set>

                <td name='<c:out value="${dataset.rows[c].chreqprofile_id}" />' >
                    <table width="100%" frame="below" cellPadding="0" cellSpacing="0"style="border-right: 1px solid gray;">

                        <%if( col < iElements){%>
                            <tr style="height:10mm">
                                <td class="td_function" style="cursor:default;">
                                    <c:out value="${dataset.rows[c].description}" />
                                </td>
                            </tr>
                            .................
                            <tr style="height:14mm">                        
                                <td class="td_signature" align="center" vAlign="middle">
                                    <img class="img_signature"
                                         src='../xdata/signatures/<c:out value="${dataset.rows[c].responsible_name}"/>.<%=signExt%>'
                                         alt='<c:out value="${dataset.rows[c].email}" />' 
                                    />
                                </td>
                            </tr>
                            .................

                            <c:set var="sMail"><c:out value="${dataset.rows[c].email}"/></c:set>
                            <% if( col < iElements-1){
                                    to = to + pageContext.getAttribute("sMail").toString() + ","; 
                               }else{
                                    to = to + pageContext.getAttribute("sMail").toString();
                               }
                            %>                      
                        <%}else{%>
                            <tr style="height:10mm">
                                <td class="td_function" style="cursor:default;">x</td>
                                .............
                            </tr>
                        <%}%>
                    </table>
                </td>               

                <%}%>
            </tr>
            <%
                if( col >= iElements){break;}
            }%>
        </table>
        <span id="span_mail_to" style="display:none;"><%=to%></span>        
    </c:when>   
    <c:when test="${param.action == 'functions_form_insert'}">  
        .............
    </c:when>   
</c:choose>

Answer 6

Вот таблица, сравнивающая JSP и Facelets, которые могут быть кому-то полезны, где-то:

Источник