Fælles felter i ding_content

Submitted by RunePhilosof on 15 January, 2013 - 15:06

Jeg kan ikke forstå hvorfor det er smart at fjerne alle fælles felter fra ding_content for at ding_event, ding_news, ding_page, ... kan have deres egne, f.eks. lead eller library

Samtidig har næsten alle felterne ens administrativ titel, så de er (næsten) umulige at kende forskel på i GUIen

Det gør det også meget besværligt at lave et view hvor man vil gøre noget med både nyheder og arrangementer og muligvis begrænset på library.

Så jeg synes der skal være et ding_library felt i ding_content som bruges i både ding_event og ding_news.

Grupper:

Kommentarer

xen6 years ago

Er sådan set enig, det giver

Er sådan set enig, det giver ikke den store mening at alle moduler skal definere deres ejen field_library fra bunden af, men delte felter giver også nogen problemer.

Men de kan ikke placeres i ding_content, da den ikke indeholder nogen content typer. Det kræver også at alle moduler der bruger et givent felt skal være enige om den fælles konfiguration, da den vil blive dumpet til alle modulerne.

RunePhilosof6 years ago

Felter i ding_content

Det er muligt at eksportere felter i features uden en content type.

xen6 years ago

Ja, men den exporterer stadig

Ja, men den exporterer stadig en hel felt definition, inkl. instance data. Det vil sige at den stadig peger på den content type man exportere den fra. Hvilket burde gøre den vrissen når featuren bliver enabled og den ikke kan finde content typen, men med Features ved man sgu aldrig.

RunePhilosof5 years ago

Features 2.0

I features 2.0 er base og instance separeret.

Ding2tal er gået over til features 2.0 allerede.