RichFaces 3 к RichFaces 4 миграция


В настоящее время я работаю над проектом, который хотел бы перенести на RichFaces 4 из версии 3.3.3.Окончательный. Мне было интересно...

  • Есть ли что-то важное, о чем я должен думать, знать или думать перед миграцией?

  • (может быть, глупый вопрос, но.....) можете ли вы "смешать" richfaces 3 с richfaces 4?

Одна из главных причин, по которой я хотел сделать переключатель, - это использовать автозаполнение richfaces 4, Есть ли способ сделать что-то подобное использование richfaces 3 или миграция будет самой простой?

Я использую JSF.

2   3   2012-09-25 18:25:01

2 ответа:

есть ли что-то важное, о чем я должен думать, знать или думать перед миграцией?

Их рекомендация состоит в том, чтобы следовать их собственным RichFaces 3.3.х-4.X руководство по миграции - которое кажется далеко не полным, см. ответEJP ниже для реального опыта.


(может быть, глупый вопрос, но.....) можете ли вы "смешать" richfaces 3 с richfaces 4?

Нет, вы не можете. сам.

Здесь следует отметить, что официальное руководство по миграции заполнено не более чем на 30%. В качестве метрики я написал таблицу стилей XSLT из 378 строк в 2011 году на основе руководства по миграции. Затем я оставил проект в бездействии до июня 2015 года, и на основе дальнейших исследований и получения его работы он уже дошел до 1090 строк. Принимая во внимание, что любая таблица стилей XSLT имеет некоторые накладные расходы, 378/1090 = около 35%.

После того, как вы сделаете то, что сказано в миграции Руководство:

  1. Откройте документацию, созданную TLD/VLD для каждого компонента, который вы используете на соседних вкладках браузера, по одной для каждой версии, и тщательно сравните их. Существуют десятки недокументированных изменений в именах и целях атрибутов, и некоторые атрибуты были перемещены из родительских контейнеров в дочерние контейнеры.

  2. Есть также важные вещи, которые только что были произвольно удалены, такие как rich:page и rich:layout.

    Я приведу список некоторых из них. дополнительные вещи, которые я обнаружил в конце этого.

  3. Затем вы столкнетесь с неприятным осознанием того, что они также изменили большое количество собственных имен классов стилей, поэтому, если вы определили стили для любого из них в своей собственной таблице стилей, вам предстоит еще много работы.

  4. вы также обнаружите, что их утверждение о том, что вы можете определить свои собственные классы стилей и указать их в богатых компонентах для реализации своих собственных стилей, просто неверный. Ваши классы стилей применяются на уровне содержания, но во многих случаях, таких как ячейки таблицы, они посчитали нужным определить шрифты и т. д. На уровне ячеек таблицы, где единственный способ переопределить их-переопределить стили ячеек по имени.
  5. вы также должны убедиться, что ваша таблица стилей включена после богатых граней. В 3.3 это было автоматически, так как их включили первыми. Теперь они включены последними, поэтому вы должны использовать h:outputStylesheet и сделать это как можно позже, чтобы обеспечить она генерируется впоследствии.

Я использовал преобразование XSLT для реализации руководства по миграции и выполнения 1-2 выше. В настоящее время он насчитывает более 1000 строк, и я еще ни в коем случае не закончил. Почему они сами не могли предоставить такую вещь, для меня остается загадкой.

Почему было сочтено необходимым внести такие значительные изменения между выпусками 3 и 4, является еще одной и более глубокой загадкой. Это очень плохо управляемый продукт. Я не буду переносить его снова или развертывать его заново.

EDIT недокументированные изменения, которые я нашел (используя синтаксис XPath для краткости):

  • a4j:status

    1. Документация неясна по этому вопросу, но атрибут for= был удален: теперь он работает по умолчанию в пределах ближайшего родителя a4j:region, если только нет привязки к определенным виджетам через атрибуты status=. Так что если у вас есть несколько в пределах одного региона, они теперь все будут стрелять.

    2. Если вы этого хотите применитесь к конкретному виджету через status= вы должны изменить соответствующий атрибут a4j:status/@id на атрибут @name.

    3. После того, как вы исправите все это, он все еще не работает:

      • An a4j:status with @for (removed) attribute won't stop
      • с атрибутом @name и нет @id ничего не сделает
      • и с обоими @name и @id не остановится.
  • rich:column/@breakBefore

    Теперь breakRowBefore

  • rich:page

    Удалено.

  • rich:layout

    Удалено.

  • rich:column/@sortOrder

    Теперь должно быть в нижнем регистре.

  • rich:dropDownMenu/@value

    Теперь rich:dropDownMenu/@label

  • rich:dropDownMenu/@direction и rich:dropDownMenu/@jointPoint

    Значения для них были изменены с {top-left, top-right, bottom-left, bottom-right} и {tl, tr, bl, br} соответственно на {topLeft, topRight, bottomLeft, bottomRight}.

  • rich:contextMenu/@submitMode, rich:dropDownMenu/@submitMode, rich:menuItem/@submitMode

    Это теперь все сейчас rich:<whatever>/@mode, а значение "none" необходимо изменить на "client".

  • rich:isUserInRole

    Это просто перестало работать, по крайней мере для меня, с Mojarra 2.2.08 и EL 2.2. К счастью, с EL 2.2 он вам больше не нужен и вы можете использовать request.isUserInRole(...).
  • rich:menuGroup/@value

    Теперь rich:menuGroup/@label.

  • rich:tab/@label

    Теперь rich:tab/@header.

  • rich:tab/f:facet/@name[.='label']

    Теперь rich:tab/f:facet/@name[.='header'].

  • rich:tabPanel/@activeTabClass, rich:tabPanel/@contentStyle, rich:tabPanel/@disabledTabClass, rich:tabPanel/@inactiveTabClass, rich:tabPanel/@tabClass

    Теперь tabActiveHeaderClass, tabContentClass, tabDisabledHeaderClass, tabHeaderClass, tabInactiveHeaderClass, tabContentClass соответственно.

  • rich:tree/@adviseNodeOpened

    Это было удалено и rich:treeNode/@expanded добавлено. Это не очень хорошо документировано: это должно быть EL, например "#{true}", а не "true", и это может быть свойством Боба узла дерева, например "#{node.expanded}", или любого другого Боба; должно быть булевым. (То же самое верно и для нового атрибута rich:collapsibleSubTable/@expanded.)

  • rich:tree/@nodeFace

    Теперь rich:tree/@nodeType.

  • rich:tree/@switchType

    Теперь rich:tree/@toggleType и возможно rich:tree/@selectionType.

  • rich:tree/@treeNodeVar

    Теперь var, или, возможно, просто удален.

  • rich:treeNodesAdaptor

    Теперь rich:treeModelAdaptor, и больше не обрабатывает массивы, наборы узлов,... или что-нибудь не Map или Iterable. Он также потерял свой атрибут var, который, насколько я могу видеть, полностью разрушает его для вложенного использования. Единственный доступный сейчас атрибут var - это атрибут предка rich:tree. Так, например, если вы хотите, чтобы родительский узел и текущий дочерний узел были одновременно времени у них просто нет. Это изменение влечет за собой либо нетривиальное переписывание, либо следующий Клудж.

    Старый:

    <rich:tree>
        <rich:treeNodesAdapter var="vm_host">
            <rich:treeNode .../>
            <rich:treeNodesAdapter var="vm_guest">
                <rich:treeNode .../>
            </rich:treeNodesAdapter>
        </rich:treeNodesAdapter>
    </rich:tree>
    

    Новое:

    <rich:tree ... var="node"> <!-- Add a 'var' attribute -->
        <rich:treeModelAdapter>
            <c:set var="vm_host" value="#{node}"/>
            <rich:treeNode .../>
            <rich:treeModelAdapter>
                <c:set var="vm_guest" value="#{node}"/>
                <rich:treeNode .../>
            </rich:treeModelAdapter>
        </rich:treeModelAdapter>
    </rich:tree>
    

    Можно также использовать <ui:param> вместо <c:set>.

Процесс преобразования значительно усложняется отказом RichFaces проверять имена атрибутов на наличие ошибок. Вы можете продолжать использовать старые имена, но они просто не работают.