Aller au contenu principal

Fehler bei Wandelung CAL => FS_LIST

Zendesk API User

Author: arnbae
Publication Date: 7/17/2012 8:45

Hallo,

ich habe keinen Hinweis in irgendeiner Doku / Release Note gefunden, die darauf hindeuten würde, dass man einen CMS_INPUT_CONTENTAREALIST nicht durch Umstellen des Formulars auf FS_LIST bringen könnte. Dies ist natürlich auch in Hinblick auf 5.0 essentiell.

Nun habe ich folgenden Fall in FS  4.2.468.50982 (FS 4.2R4):

CAL:

  <CMS_INPUT_CONTENTAREALIST name="st_contentarealist_1" hFill="yes" rows="7">
    <LANGINFOS>
      <LANGINFO lang="*" label="Picture gallery:" description="List of all pictures for the gallery."/>
      <LANGINFO lang="DE" label="Bildergalerie:" description="Liste aller Bilder der Galerie"/>
      <LANGINFO lang="EN" label="Picture gallery:" description="List of all pictures for the gallery"/>
    </LANGINFOS>
    <SOURCES>
      <TEMPLATE name="pictureblock"/>
    </SOURCES>
    <VARIABLES>
      <VARIABLE name="st_picture_1"/>
      <VARIABLE name="st_link_1"/>
      <VARIABLE name="st_dom_5"/>
      <VARIABLE name="st_picture_2"/>
    </VARIABLES>
  </CMS_INPUT_CONTENTAREALIST>

wird ersetzt durch:

  <FS_LIST name="st_contentarealist_1" hFill="yes" rows="10">
    <DATASOURCE type="inline" useLanguages="no">
      <LABELS>
        <LABEL lang="*">"Bild: \"" + #item.st_picture_1 + "\" | Bildunterschrift: \"" + #item.st_dom_5.toText(false) + "\" | Lightbox: \"" + #item.st_picture_2 + "\""</LABEL>
      </LABELS>
      <ACTIONS>
        <ACTION name="ADD"/>
        <ACTION name="REMOVE"/>
        <ACTION name="UP"/>
        <ACTION name="DOWN"/>
        <ACTION name="EDIT"/>
        <ACTION name="DETACH"/>
      </ACTIONS>
      <COLUMNS>
        <COLUMN show="no">#identifier</COLUMN>
      </COLUMNS>
      <LAYOUT>
        <ADD component="toolbar" constraint="top"/>
        <ADD component="overview" constraint="center"/>
        <ADD component="stackedview" constraint="bottom">
          <PARAM name="show-language-tabs">yes</PARAM>
        </ADD>
      </LAYOUT>
      <TEMPLATES source="sectiontemplates">
        <TEMPLATE uid="pictureblock"/>
      </TEMPLATES>
    </DATASOURCE>
    <LANGINFOS>
      <LANGINFO lang="*" label="Picture gallery:" description="List of all pictures for the gallery."/>
      <LANGINFO lang="DE" label="Bildergalerie:" description="Liste aller Bilder der Galerie"/>
      <LANGINFO lang="EN" label="Picture gallery:" description="List of all pictures for the gallery"/>
    </LANGINFOS>
  </FS_LIST>

Jetzt hätte ich erwartet, dass die Daten in neuem Gewand erscheinen. Das funktioniert aber nur in ca. 10% aller Fälle. In den meisten Fällen bekommen wir im Java-Client beim Aufruf des Formulars die (blutrote) Meldung:

Hinweis
Fehler in der Vorlage '2011: Picture Gallery': Der ausgewählte Inhalt kann nicht angezeigt werden.
Grund: Not null Template expected
Details
java.lang.IllegalStateException: Not null Template expected.
          at de.espirit.firstspirit.access.store.templatestore.gom.fslist.AbstractListDataFactory.deepCopy(AbstractListDataFactory.java:106)
          at de.espirit.firstspirit.client.access.editor.FsListEditorValueImpl.copy(FsListEditorValueImpl.java:131)
          at de.espirit.firstspirit.client.access.editor.FsListEditorValueImpl.adopt(FsListEditorValueImpl.java:111)
          at de.espirit.firstspirit.client.access.editor.FsListEditorValueImpl.adopt(FsListEditorValueImpl.java:41)
          at de.espirit.firstspirit.client.access.editor.AbstractEditorValue.definitelySet(AbstractEditorValue.java:636)
          at de.espirit.firstspirit.client.access.editor.AbstractEditorValue.parseDataElement(AbstractEditorValue.java:419)
          at de.espirit.firstspirit.client.access.editor.AbstractEditorValue.setValueNode(AbstractEditorValue.java:359)
          at de.espirit.firstspirit.client.access.editor.AbstractEditorValue.initialize(AbstractEditorValue.java:125)
          at de.espirit.firstspirit.module.GadgetSpecification$ValueMediatorFactoryImpl.createValue(GadgetSpecification.java:206)
          at de.espirit.firstspirit.module.GadgetSpecification$ValueMediatorFactoryImpl.createValue(GadgetSpecification.java:186)
          at de.espirit.firstspirit.client.access.editor.EditorValueFactory.create(EditorValueFactory.java:61)
          at de.espirit.firstspirit.client.access.editor.EditorValueFactory.create(EditorValueFactory.java:46)
          at de.espirit.firstspirit.store.access.DataImpl.create(DataImpl.java:180)
          at de.espirit.firstspirit.store.access.DataImpl.create(DataImpl.java:161)
          at de.espirit.firstspirit.store.access.DataBuilder.toData(DataBuilder.java:108)
          at de.espirit.firstspirit.store.access.DataProviderHelper.getData(DataProviderHelper.java:123)
          at de.espirit.firstspirit.store.access.pagestore.SectionImpl.getData(SectionImpl.java:320)
          at de.espirit.firstspirit.client.gui.tree.store.pagestore.GomModuleView.setElement(GomModuleView.java:143)
          at de.espirit.firstspirit.client.gui.tree.store.pagestore.GomModuleView.<init>(GomModuleView.java:68)
          at de.espirit.firstspirit.client.gui.tree.store.pagestore.PSPageView.getView(PSPageView.java:208)
          at de.espirit.firstspirit.client.gui.tree.store.pagestore.PSPageView.constructComponent(PSPageView.java:139)
          at de.espirit.firstspirit.client.gui.tree.store.AbstractAccessTabbedView.getViewableComponent(AbstractAccessTabbedView.java:338)
          at de.espirit.firstspirit.client.gui.tree.store.AbstractAccessTabbedView.getComponent(AbstractAccessTabbedView.java:193)
          at de.espirit.firstspirit.client.gui.tree.store.AbstractAccessTabbedView.access$100(AbstractAccessTabbedView.java:50)
          at de.espirit.firstspirit.client.gui.tree.store.AbstractAccessTabbedView$1.tabSelected(AbstractAccessTabbedView.java:152)
          at de.espirit.firstspirit.client.gui.tree.store.AbstractAccessTabbedView$SubTabModel$2.invoke(AbstractAccessTabbedView.java:617)
          at de.espirit.firstspirit.client.gui.tree.store.AbstractAccessTabbedView$SubTabModel$2.invoke(AbstractAccessTabbedView.java:616)
          at de.espirit.firstspirit.client.gui.tree.store.AbstractAccessTabbedView$SubTabModel.notifyListeners(AbstractAccessTabbedView.java:669)
          at de.espirit.firstspirit.client.gui.tree.store.AbstractAccessTabbedView$SubTabModel.notifyTabSelected(AbstractAccessTabbedView.java:615)
          at de.espirit.firstspirit.client.gui.tree.store.AbstractAccessTabbedView$SubTabModel.selectTab(AbstractAccessTabbedView.java:605)
          at de.espirit.firstspirit.client.gui.tree.store.AbstractAccessTabbedView$SubTabModel.select(AbstractAccessTabbedView.java:558)
          at de.espirit.firstspirit.client.gui.tree.store.AbstractAccessTabbedView.getComponent(AbstractAccessTabbedView.java:234)
          at de.espirit.firstspirit.client.gui.tree.store.AbstractGuiStoreElement.getView(AbstractGuiStoreElement.java:1071)
          at de.espirit.firstspirit.client.gui.tabbing.ElementTabConfiguration$ElementView.getViewComponent(ElementTabConfiguration.java:261)
          at de.espirit.firstspirit.client.gui.tabbing.TabContentView$ComponentFactory.getRealComponent(TabContentView.java:398)
          at de.espirit.firstspirit.client.gui.tabbing.TabContentView$ComponentFactory.call(TabContentView.java:371)
          at de.espirit.firstspirit.client.gui.tabbing.TabContentView$ComponentFactory.call(TabContentView.java:251)
          at de.espirit.firstspirit.client.gui.util.GuiUtil$CallableWrapper.call(GuiUtil.java:1508)
          at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
          at java.util.concurrent.FutureTask.run(Unknown Source)
          at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
          at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
          at java.lang.Thread.run(Unknown Source)

Das ist für eine Migration zu 5.0 ein ganz schöner Showstopper. Wenn ich mit dem Absatztemplate einen neuen Absatz anlege, funktioniert alles, ebenso wie erwähnt bei ca. 10% der Altdaten. Das sollte doch normalerweise funktionieren, oder?

Festzustellen ist, dass bei einem XMLdump (Developer Scripts) die alten CALs aus <SECTION>-Tags bestehen und die neuen aus <ENTRY>-Tags. Anscheinend stellt FS bei einem Editieren der CAL ebenfalls die Tags von SECTION auf ENTRY um. Derart umgewandelte CALs lassen sich dann auch (erster Anschein, nicht ausführlich geprüft) als FS_LIST editieren.

In der Doku habe ich keinen entsprechenden Hinweis gefunden. Deshalb meine Fragen:

  • Ist das Verhalten so wie vermutet?
  • Müssen also also CALs einmal editiert und wieder gespeichert werden, bevor man das Interface auf FS_LIST ändert??
  • Gibt es dazu ein Migrationsscript von e-spirit???
  • Ticken da noch weitere Zeitbomben????

Grüße,

Arndt

Tags: cms_input_contentarealist, contentarealist, fs_list, fs_list_inline, migration

Associé à

0

Commentaires

9 commentaires

Date Votes
  • Zendesk API User
    Author: gockel - 7/17/2012 9:13

    Hallo Arndt,

    Wenn ich das richtig sehe, ist das Problem intern bereits adressiert unter #120333

    Bitte wende dich mit diesem Problem an den Helpdesk, um das zu bestätigen und ggfls. ein entsprechendes FS-Update zu erhalten.

    Gruss

    0
  • Zendesk API User
    Author: arnbae - 7/17/2012 9:17

    Danke, werde ich machen!

    Grüße,

    Arndt

    0
  • Zendesk API User
    Author: Peter_Jodeleit - 7/17/2012 10:16

    Geht es hier um eine Migration von FirstSpirit 3.1? Bzw. stammen die Daten noch aus 3.1?

    Beim Umstieg von 3.1 auf 4.x müssen alle Daten neu geschrieben werden...

    0
  • Zendesk API User
    Author: arnbae - 7/17/2012 10:54

    Ja, das ist ziemlich wahrscheinlich, dass die Daten noch aus der Migration 3.1 => 4.2 stammen. Das Neu-Schreiben hätte doch aber der Migrationsassistent übernehmen sollen / können?

    Oder anders ausgedrückt: Wann hätte das Schreiben der Daten stattfinden sollen?

    0
  • Zendesk API User
    Author: Peter_Jodeleit - 7/17/2012 11:34

    Ja, das ist ziemlich wahrscheinlich, dass die Daten noch aus der Migration 3.1 => 4.2 stammen. Das Neu-Schreiben hätte doch aber der Migrationsassistent übernehmen sollen / können?

    Nein, der Migrationsassistent hatte keinen Menüpunkt dafür.

    Das FS_LIST keine 3.1er Daten von CMS_INPUT_CONTENTAREALIST / CMS_INPUT_LINKLIST / ... versteht, müsste in den Release-Notes der Version stehen, mit der FS_LIST eingeführt wurde.

    [EDIT]

    Ein ähnliches Verhalten hat man übrigens auch, wenn ein verwendetes Template gelöscht wurde (kann nur ein Admin). Dann kann / konnte aber auch die CMS_INPUT_CONTENTAREALIST keine Inhalte anzeigen.

    Eventuell kontrollieren Sie noch mal, ob nicht vielleicht dieses Problem vorliegt.

    0
  • Zendesk API User
    Author: arnbae - 7/17/2012 12:01

    Peter Jodeleit schrieb:

    Nein, der Migrationsassistent hatte keinen Menüpunkt dafür.

    Das FS_LIST keine 3.1er Daten von CMS_INPUT_CONTENTAREALIST / CMS_INPUT_LINKLIST / ... versteht, müsste in den Release-Notes der Version stehen, mit der FS_LIST eingeführt wurde.

    Das müsste (=sollte) eigentlich in der Migrationsanleitung stehen :smileywink:. Selbst wenn ich es mal in einer Release Note gelesen hatte, ist seitdem wieder viel Wasser den Bach hinuntergeflossen.

    Peter Jodeleit schrieb:

    [EDIT]

    Ein ähnliches Verhalten hat man übrigens auch, wenn ein verwendetes Template gelöscht wurde (kann nur ein Admin). Dann kann / konnte aber auch die CMS_INPUT_CONTENTAREALIST keine Inhalte anzeigen.

    Eventuell kontrollieren Sie noch mal, ob nicht vielleicht dieses Problem vorliegt.

    Das hatte ich als erstes gecheckt - das Problem liegt nicht vor. Wie gesagt, es ist alles in Butter, wenn man die CAL-Daten einmal edititiert und dann die CAL im Formular gegen FS_LIST austauscht. Dann hat FS die Daten gewandelt. Oder eben bei CAL-Daten, die neu eingegeben und nicht migriert wurden.

    Ganz offensichtlich besteht im Migrationspfad eine Lücke zwischen CAL-Format <alt> (FS 3.1 und migrierte Daten in FS 4.2) und CAL-Format <neu> (neu erzeugte CAL-Daten in 4.2), welche anstandslos in FS_LIST übernommen werden. Diese Lücke scheint mir nur durch Editieren und Speichern der CAL zu schließen sein.

    Bin mal gespannt, wie viele Firmen noch migrierte, 2 Jahre alte CALs in ihren Daten haben, mit Erscheinen der 5.0 auf FS_LIST umsteigen, und dann sehen, dass sie an die alten Daten nicht mehr heran kommen.

    0
  • Zendesk API User
    Author: andre - 7/17/2012 13:43

    > Bin mal gespannt, wie viele Firmen noch migrierte, 2 Jahre alte CALs in ihren Daten haben, mit Erscheinen > der 5.0 auf FS_LIST umsteigen, und dann sehen, dass sie an die alten Daten nicht mehr heran kommen.

    von 2 Jahre alten Cals kann man hier ja nicht reden, sondern von weit aus älteren. Desweiteren sind/waren die FS-Komponenten bis hierhin immer als in entwicklung definierte Komponentengruppe markiert (siehe ODFS)

    --------------

    "Da die offizielle Freigabe erst mit FirstSpirit™ Version 5.0 erfolgen wird, die Eingabekomponenten („FS_“) aber bereits in FirstSpirit™ Version 4.2 eingesetzt werden können, erhalten sie in Version 4.2 den Status „in Entwicklung“."

    -------------

    fuer FS-5 (bisher ja nicht offiziell released), wird es mit Migrations best-practice geben, ausserdem werden Meldungen geloggt, welche auf eine 3.1er Daten-Format hinweisen.

    0
  • Zendesk API User
    Author: Peter_Jodeleit - 7/17/2012 13:58

    Das müsste (=sollte) eigentlich in der Migrationsanleitung stehen :smileywink:.

    Ich habe das mal in unserem internem Ticketsystem unter der angegebenen ID (#120333) ergänzt.

    Diese ID behandelt übrigens das von André erwähnte Logging für die Version 4.2.R4.

    0
  • Zendesk API User
    Author: arnbae - 7/17/2012 14:00

    Andre Pfeiler schrieb:

    von 2 Jahre alten Cals kann man hier ja nicht reden, sondern von weit aus älteren.

    Nur unter der Annahme, dass beim Erscheinen der neuen Release gleich migriert wurde! Ich muss zugeben, dass kaum jemand so spät dran gewesen sein dürfte wie wir :smileycry:, aber nach allem, was ich von Kollegen gehört habe, tat man gut daran, bis zur 4.2 mit der Migration zu warten.

    Wenn in der 5.0 dann die 3.1er-Strukturen angemahnt werden, ist das ja schön und gut, nur verbaut mir das letztendlich die Möglichkeit, bereits in FS 4.2 meine Templates so weit umzustellen, dass das Upgrade zur 5.0 reibungslos und in einem engen Zeitfenster verläuft. Außerdem kann ich meinen Redakteuren erst nach der Umstellung den Komfort der FS_LIST bieten. Und bevor wir auf die 5.x gehen, darf die ruhig ein halbes Jahr reifen :smileywink:

    0

Vous devez vous connecter pour laisser un commentaire.

Ce n’est pas ce que vous cherchez ?

Nouvelle publication