Как избежать дублирования с помощью EL? - PullRequest
Новая
       44

Как избежать дублирования с помощью EL?

2 голосов
/ 10 марта 2012

Я переписываю свой. jsp из скриптов в JSTL / EL, и я столкнулся с проблемой.Это, наверное, очень просто, но я новичок в EL и немного потерян.

Вот что я делаю ...

В сервлете / контроллере: 

final List<Person> l = new ArrayList<Person>();
personList.add(...);
.
.
request.setAttribute( "personList", l );

И в моем. jsp : 

<c:forEach var="person" items="${personList}">
    ${person.name}
</c:forEach>

Но я дублирую "personList", потому что я использую его как в setAttribute , так и в Foreach .Как я могу избавиться от этого дублирования?

В идеале я хотел бы иметь константу, такую ​​как public static final final String , на которую я мог бы ссылаться как из сервлета, так и из .jsp (используя EL, а не скриптлеты).

Очевидно, что причина, по которой я хочу устранить это дублирование, заключается в том, что если я решу переименовать personList , скажем, people (с 's'), мне нужно изменить две вещи, и это подвержено ошибкам.Если бы у меня была константа, было бы только одно место, где мне нужно было бы внести это изменение.

РЕДАКТИРОВАТЬ кто-то сказал, что при использовании константы все равно должно быть два местаизменить, если я изменил имя константы.Однако есть большая разница, если бы я мог сделать это:

request.setAttribute (Constants.PERSON_LIST, l);

затем решите переименовать * PERSON_LIST * и сделаете опечатку, которая сломаетсяво время компиляции.

В то время как если я наберу неправильный тип: 

request.setAttribute( "persnList", l ); // forgetting an 'o' here

Это будет неуклюже скомпилироваться и завершится с ошибкой, если .jsp использует "personList", а неопечатка "persnList".

Ответы [ 3 ]

1 голос
/ 10 марта 2012

Это то, что вы получаете при работе с устаревшими / базовыми JSP / сервлетами. Вы вручную выполняете все задачи фронт-контроллера.

Переходите к реальной структуре MVC. Например, JSF, Spring MVC, Wicket и т. Д. Эти фреймворки имеют один сервлет (или фильтр), который действует как фронт-контроллер, выполняющий всю неприятную работу по предварительной обработке - создание бинов, помещение их в желаемую область и т. Д. Вы заканчиваете работу с использованием только javabeans в качестве моделей и файлов JSP / Facelets в качестве представлений. Например, в JSF все, что вам нужно, это следующий javabean (который будет «автоматически» установлен в области запроса самим JSF): 

@ManagedBean
@RequestScoped
public class Persons {

    private List<Person> list;

    @EJB
    private PersonService service;

    @PostConstruct
    public void init() {
        list = service.list();
    }

    public List<Person> getList() {
        return list;
    }

}

И этот вид Facelet: 

<ui:repeat value="#{persons.list}" var="person">
    #{person.name}
</ui:repeat>

Без дублирования и при использовании достойных инструментов IDE (например, Eclipse с JBoss Tools) все они связаны друг с другом, так что вы можете Source> Refactor> Rename безболезненно.

0 голосов
/ 10 марта 2012

Возможно я ошибаюсь, но я думаю, что стандартная проблема с jsps - вы не видите ошибок до тех пор, пока страница не загрузится.Даже если константы это как-то исправят, то, что вы описываете, это не дублирование, а недостаток переменных EL в целом (то есть они динамически просматриваются во время выполнения)

0 голосов
/ 10 марта 2012

Не правда ли, дублирование?Это просто объявление переменной и доступ к переменной в одной области видимости.Это прекрасно.Если вы пишете программу и объявляете переменную в одной строке, а затем в программе вы получаете доступ к переменной, то у вас возникает та же проблема ... если вы измените имя переменной, как объявлено, то все варианты использования должны быть найдены и изменены.

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

...