Почему фреймворки веб-разработки имеют тенденцию работать вокруг статических особенностей языков?

Question

Когда я начал использовать Lift, я был немного удивлен тем, насколько интенсивно он использует отражение (или кажется), что было немного неожиданно для статически типизированного функционального языка. Мой опыт работы с JSP был похожим.

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

1. Какие аспекты веб-разработки поощряют использование рефлексии?

2. Существуют ли какие-либо инструменты (в статически типизированных языках), которые обрабатывают (1) обращение к коду со страницы шаблона (2) объектно-реляционное отображение способом, не использующим отражение?

Answer 1

Пожалуйста, смотрите источник лифта. Он не использует отражения для большей части кода, который я изучал. Почти все статически типизировано. Если вы ссылаетесь на виды лифта, они обрабатываются как узлы Xml, это тоже не отражение.

Answer 2

В частности, ссылаясь на <lift:Foo.bar/> вопрос:

когда <lift:Foo.bar/> встречается в коде, Lift делает несколько предположений о том, каким должно быть исходное имя (различные соглашения об именах), а затем вызывает java.lang.Class.forName чтобы получить класс. (Соответствующий код в LiftSession.scala а также ClassHelpers.scala.) Он найдет только классы, зарегистрированные с addToPackages во время загрузки.

Обратите внимание, что также можно (и часто) регистрировать классы и методы вручную. Конвенция по-прежнему заключается в том, что все преобразования должны иметь форму NodeSeq => NodeSeq потому что это единственное, что имеет смысл для нетипизированного вывода HTML/XHTML.

Итак, у вас есть внутренний реестр преобразований узлов Lift с одной стороны, а с другой стороны - неявный реестр модуля. Оба типа используют простой поиск строки для выполнения метода. Я предполагаю, что это спорно, если один больше отражения на основе других.