webEdition - Forum

In Nova (Laravel) gibt es Felder in denen einfache key:value Werte eingetragen werden können. Das bietet sich gut für einfache wiederholende Daten an. Eventuell wäre das ja ein Kompromis. Gespeichert wird das als json in der DB.

ich sehe hier wie in qa angedeutet, keinen Wettbewerb zu Dokumenten. In Dokumenten kann man frei gestalten, in Objekten folgt man einer klar vorgegebenen Struktur. Eine Überfrachtungsgefahr sehe ich dann, wenn die Oberflächengestaltung nicht entsprechend passend ist (also eher eine GUI-Herausforderung). Das Beispiel aus qa aufgreifend (mehrere Dokumente in einem Objekt verlinken) könnte ähnlich Multiobjekten mit einer Referenz zu einer zentralen Tabelle (ggf. Tabelle je Typ href, img, etc.) als commaseparierte Werte abgespeichert werden.

Oha, also geht es gar nicht um ein we:block in dem alles Mögliche drin sein könnte... sondern um die Referenz auf ein Dokument?

Wie von Thomas geschrieben key:value Werte?
Soll pro Block vorgegeben sein, das möglich ist über bspw. types="href,img" und der Redakteur wählt dann pro Eintrag aus, um was es sich konkret handelt?
Oder soll pro Block eine Art fest definiert sein bspw. über type="href" ... wobei man hier wieder int,ext,all berücksichtigen müsste?

für mein Empflnden würde es ausreichen, einen Feldtyp zu definieren, z.B. href und dann die Option "Anzahl" zu aktivieren mit ggf. einer weiteren Option "max". Der Redakteur kann dann n-href Elemente angeben, aber eben nur href und nicht irgendwas.

Abruf wäre evtl. analog Multiobjekt denkbar.

Ein Anwendungsfall sind z.B. Bildergalerien. Da hast du ein News Obekt, in dem es is zu x Bilder geben soll. Heute müssen dafür dann x Feldes des Typs Bild angegeben werden. Alternativ kann natürlich mit Sammlungen oder Verlinkung zu einem Dokument mt einem we:block gearbeitet werden. Aber beides ist sehr umständlich in der Pflege, wenn doch nur mal eben eine News mit drei Bildern angelegt werden soll.
Die x Bilder Felder sind auch sehr unschön in der Bearbeitung. Ein Multifield könnte hier den Komfort für Redakteure deutlich verbessern.

Aber löst man das Beispiel von Thomas nicht ehr mit einer Sammlung?

Wäre dann vielleicht hilfreich, wenn man nicht nur eine Sammlung auswählen, sondern auch eine Neue anlegen könnte

Mir gefällt die Idee überhaupt nicht.

Die Objekte sind für strukturierte Daten und selbst bei "href mit Anzahl", wie weiter oben vorgeschlagen ist doch die Frage wie man das DB-technisch einfach, allgemein und performant abfackelt.

Wir haben die multiobjecte für sowas und in der 9 sogar Felder zum Sortieren ...

Meine Befürchtung ist einfach, das die z.Z. sehr performaten Objecte dadurch nur langsamer würdem

Objekte bilden die Daten 1:1 auf die Tabellenstruktur ab. Es gibt keinen Tabellentyp der 1-20 Werte hat.

Für alles woraus nur die ganze Struktur wieder rauskommt, kann man natürlich einen neuen Typ generieren.
d.h. ein Typ "linklist" oder "keyvalue" ist schon denkbar - in der DB sind das am Ende natürlich serialisierte Daten - also eine Abfrage gibt es einen Datensatz wo ein Link auf Dokument 1712 gibt, ist nicht sinnvoll möglich - oder auch ob ein key-value den Wert 13 enthält. Aber bei der Ausgabe eben die Links oder Key-Values auszugeben geht natürlich.

Vielleicht reicht auch schon eine Änderung des GUI. D.h. wenn ich z.B. eine Linklsit möchte, dann legt we im Hintergrund eben x Felder des Typs Link an aber für den Redakteur sieht es aus wie ein we:block. D.h. im Grunde einer Erweiterung der we:fold überlegung.

das geht auch nicht. Ein Objekt kann auch maximal nur 60 Felder besitzen. Ich finde die Idee nicht so blöd - aber sie hat eben auch Einschränkungen, genau wie multiobjekt ja auch - das ist ja im Prinzip genau sowas was du auch willst (also multiImg, multiHref, ..)

Ob das dann immer MultiXX heißen muß, halte ich für blöd, wäre aber im Backend durchaus einfacher.

Also ich bin auch hin und her gerissen. Die Argumentation mit dem Zweck von Objekten verstehe ich. Andererseits habe ich auch ein Projekt wo ich n PDF Dokumente im Objekt hinterlegen wollen würde ohne erst "umständlich" eine Sammlung anlegen zu müssen. Geht ja auch ein wenig um den Workflow.

Ich würde analog zum Multiobjekt das Multidokument unterstützen:
=> was dann Filtereinstellungen wie DocType, ContentType (Image-Dok, WE-Dok etc.), Workspace etc. aufweisen könnte

• alle weiteren hier diskutierten MultiXYZ führen uns m.M.n. von der Objekte-Grundidee weg und in der DB in Teufels Küche...

• was sicher kein Problem ist: die passenden "Neu"-Buttons ergänzen, so wie z.B. beim Sammlungsfeld schon vorhanden

• mehrere Klassen beim Multiobjekt: wäre DB-seitig und für die LV-Multiobjekt vermutlich kein Problem: da sehe ich aber den Usecase noch nicht: wenn ein Ort, ein Datum, ein Referent etc. veknüpft werden sollen, macht es doch keinen Sinn, das in einem eizelnen MO abzuhandeln... Um "Text + Bild" oder "Nur Text" anbieten zu können, würde ich eher an Objekte denken, bei denen je nach Unterverzeichnis verschiedene Felder ein- und ausgeblendet wären, aber das ist ja wieder ein ganz neues Thema

• Template für "Bearbeiten" von Objekten: klingt charmant, bedingt aber eine Menge kozeptionnelle Vorarbeit und kann ein Fass ohne Boden werden (aber vielleicht denke auch gerade zu weit)...

... wobei das mit der DB und Teufels Küche vielleicht gar nicht so schlimm ist: im Grunde lassen sich auch MultiHref und diverse andere MultiXYZ recht einfach abbilden und dann mit einer eigenen LV analog zu type=multiobject auch nutzen...