Переход с RichFaces 3 на RichFaces 4

Question

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

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

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

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

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

Answer 1

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

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

---

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

Нет, ты не можешь. Это будет противоречить самому себе.

Answer 2

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

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

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

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

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

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

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

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

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

РЕДАКТИРОВАТЬ Недокументированные изменения, которые я обнаружил (используя краткий синтаксис XPath):

• a4j:status

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

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

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

     • a4j:status с @for (удалено) атрибут не остановится
     • с @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, Так, например, если вы хотите, чтобы родительский узел и текущий дочерний узел одновременно, они просто недоступны. Это изменение влечет за собой либо нетривиальное переписывание, либо следующий кладж.

  OLD:

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

  NEW:

  <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 проверить имена атрибутов. Вы можете продолжать использовать старые имена, но они просто не работают.