Как настроить проект в Eclipse, чтобы можно было правильно проверить jsps, включая <% @ page import = "...%>в <@include file ="... ">
Пусть будет (затвор Liferay hook) проект затмения xyz-hook. И пусть там будет файл a.jsp
<% @include file="/html/portal/init.jsp" %>
<% InitImportedClass.yxz(); %>
и пусть будет включенный init.jsp в другом (указанном) проекте.
<% @page import="de.company.InitImportedClass" %>
Для a.jsp в проекте xyz-hook мы получаем предупреждение в строке 1
Fragment "/html/portal/init.jsp" was not found at expected path /xyz-hook/src/main/webapp/html/portal/init.jsp
и ошибка в строке 2
InitImportedClass cannot be resolved
Есть ли способ сказать Eclipse, чтобы он искал init.jsp в другом проекте?
На проект (ствол портала Liferay), содержащий файл init.jsp, уже имеется ссылка. Я также создал синтетический jar, содержащий также jsp, добавил его в локальный репозиторий maven и в качестве зависимости от проекта xyz-hook.
PS: Для тех, кто интересуется, это типичная настройка для ловушек Liferay при замене jsps, которые предоставляются ядром портала.
PPS: я знаю, что мог бы вообще деактивировать проверку jsp, но я бы хотел этого избежать, так как в противном случае действительно отсутствующий импорт не будет отображаться как ошибка.
1 ответ
Я бы очень приветствовал такую функцию, но, согласно моим последним разговорам о ней, ее будет действительно сложно решить и она потребует серьезных изменений во многих компонентах. Учитывая, что редактор jsp уже несколько хрупок (иногда он показывает ошибки проверки, которых там нет), я не вижу, чтобы кто-нибудь напал на него в ближайшем будущем. Но я возьму это за повод снова поникать. (Возможно, вы захотите опубликовать запрос функции на https://issues.liferay.com/browse/IDE или найти существующий и поддержать его)
Тем не менее, есть некоторые обходные пути:
С <liferay-util:include />
jsp-tag вы можете указать servletContext и включить другой JSP из вашего собственного хука. Это будет выполняться в загрузчике классов указанного веб-приложения, и Eclipse сможет с этим справиться. В вашем jsp-хуке вам все еще нужно деактивировать проверку jsp, но оставшийся JSP - это всего лишь несколько символов, которые занимаются включением, и это вполне нормально.
У вас будет немного больше работы по выяснению всего контекста и т. Д., Но если вы выполняете более тяжелую работу, это может быть вариантом. Вы также можете использовать пользовательские классы из ловушки - чего вы обычно не можете, когда вводите новый jsp в загрузчик классов портала.
Примерпсевдокода:
В вашем крючке переопределение jsps из портала, например, в my-hook/custom-jsps/html/portlet/navigation/view.jsp
<%-- omitted taglib includes --%>
<liferay-util:include
page="/jsp/navigation/view.jsp"
servletContext="<%=this.getServletContext().getContext("/my-hook")%>" />
это заменит jsp Liferay по умолчанию для портлета навигации с вашей собственной реализацией. Тем не менее, это, очевидно, не так много, но включает в себя /jsp/navigation/view.jsp
который он найдет в вашем собственном хуке (примечание: /custom-jsps
содержит jsps, которые переопределяют файлы портала в /jsp
будет обслуживаться в контексте хука:
в my-hook/jsp/navigation/view.jsp
<%-- omitted taglib includes --%>
<ul>
<li>build</li><li>your</li><li>navigation</li>
</ul>
<!-- you also have access to classes introduced by your hook -->
<%=CustomClassInHook.doSomething() %>
Недостатком является то, что вам придется "повторять" инициализацию, которую каждый Liferay jsp обычно получает самостоятельно - например, операторы импорта, сделать доступным themeDisplay и т. Д.
Также имейте в виду: выше псевдокод. Я просто набрал его здесь из некоторых (ручек и бумаги) заметок, а не прогонял. Так что это может потребовать немного больше работы и иметь другие недостатки или недостатки.
Другая возможность - разработать сложные переопределенные jsps в исходном коде Liferay и - когда это будет сделано - перенести их в свой собственный хук. Вы получите хит во время сборки, если вам нужно перестроить Liferay (но кто перестраивает для изменения jsp?), Но вы получите всю роскошь IDE