Wat kan Drupal 8 voor Symfony developers betekenen?

[Verwijderd]

Hallo,

ik moet binnenkort spreken over Drupal 8 & Symfony2. Ik geef reeds al een cursus (3 dagen) over dit onderwerp. Dit aan zowel Symfony developers als Drupal developers. Het publiek waar ik me op moet voorbereiden zijn geen Drupal developers maar vooral Symfony2 developers.

Dus ik zou graag eens weten wat het nu voor Symfony2 developers het meest interessante kan zijn over dit onderwerp? En waarom je als Symfony developer met Drupal 8 zou beginnen werken? Sowieso zeg ik al iets meer over de Symfony componenten die in Drupal 8 worden gebruikt en hoe.

Iemand nog tips voor mij?

[kwaakvaak_v2]

eindelijk een 'fatsoenlijk' CMS/CMF systeem met custom velden, revisies, goede backend form elementen etc. uit de doos. Maar geen Doctrine of propel, Drupal EFQ kan wat minder flexibel overkomen. Het neigt meer naar Doctrine DBAL wat dat betreft.

Maar de DB abstractie is zo goed dat je in theorie van DB laag kunt wisselen zonder je queries te moeten herschrijven.

[Cartman!]

Persoonlijk kan ik voor n Symfony devver geen redenen verzinnen om met Drupal te gaan werken. Gezien de reputatie van Drupal bij collega's ook denk ik dat t n lastig verhaal gaat worden. Wat vind jijzelf voordelen?

[Barryvdh]

Ik gebruikt zowel Symfony components en Drupal, dus ik zit wel op Drupal 8 te wachten. Voordeel voor mij zou zijn dat je makkelijker tools/libraries kan gebruiken, omdat ze beiden gebruiken maken van dezelfde Http foundation ed. En als ze meer op elkaar lijken, is het ook makkelijker om voor de een of de ander te ontwikkelen.

Dingen als Composer en http://drupalconsole.com/ maken het ook weer wat toegankelijker.

Ik zou het bijv. wel interessant vinden hoe ik een functionaliteit van Symfony kan gebruiken in Drupal, bijvoorbeeld door een voorbeeld module op basis van Composer.

(Als Drupal nou alleen nog even al zijn repositiories/discussies verplaatst naar Github, is het helemaal mooi )

[NMe]

Verwijderd schreef op dinsdag 03 februari 2015 @ 13:55:
Dus ik zou graag eens weten wat het nu voor Symfony2 developers het meest interessante kan zijn over dit onderwerp?

Als je blijkbaar sowieso al spreekt over Drupal én over Symfony, dan weet je dus veel van beiden af, want waarom zou je publiek anders naar jou komen luisteren. Toch noem je zelf maar één ding waar je het sowieso over wil gaan hebben. Vertel eens wat je zelf in gedachten had?

Verder: Waar hoort mijn topic?

WEB >> PRG

[kwaakvaak_v2]

Cartman! schreef op zaterdag 07 februari 2015 @ 13:47:
Persoonlijk kan ik voor n Symfony devver geen redenen verzinnen om met Drupal te gaan werken. Gezien de reputatie van Drupal bij collega's ook denk ik dat t n lastig verhaal gaat worden. Wat vind jijzelf voordelen?

Die reputatie is gebaseerd op Drupal < 8, en geheel terecht!

D8 daarentegen is een behoorlijke verschuiving. PSR4 classed, composer support, stack PHP middleware mogelijk. Ik zie voor Symfony2 developers zeker wel mogelijkheden, maar wel als ze nu ook in het CMS/CMF segment werken. Als je hele specifieke software maakt is het een nutteloze toevoeging.

[Cartman!]

Als ik even 5 minuten rondkijk op de site van Drupal wordt ik al kriegelig van de grote hoeveelheid tekst met alle uitleg terwijl ik gewoon code wil zien. Ondanks vooruitgang qua autoloading en dat er een aantal componenten vervangen zijn door die van Symfony blijft de structuur van nodes en hooks in stand waar ik gewoon niet in geloof, het mist structuur.

[kwaakvaak_v2]

nodes ja, maar dat is de basis van het systeem. Alles is een entity.. Hooks, niet helemaal waar, de meeste hooks gaan uiteindelijk een keer naar event system. Maar dat kan nog even duren, voordeel is dat het nu onder semver gaat gebeuren en dat tussentijdse releases sneller kunnen komen dan de 4+ jaar die het nu duurt per major.

En code, knock your self silly : http://cgit.drupalcode.org/drupal/tree/?h=8.0.x

[ Voor 30% gewijzigd door kwaakvaak_v2 op 09-02-2015 13:49 . Reden: semver stukje. ]

[Barryvdh]

Ik heb die repo browser van Drupal nooit echt overzichtelijk gevonden, of ligt dat aan mij? Ook patches, commits ed. zijn niet echt lekker te volgen daar. Snap echt niet dat ze niet gewoon naar Github gaan

[kwaakvaak_v2]

Barryvdh schreef op maandag 09 februari 2015 @ 13:51:
Ik heb die repo browser van Drupal nooit echt overzichtelijk gevonden, of ligt dat aan mij? Ook patches, commits ed. zijn niet echt lekker te volgen daar. Snap echt niet dat ze niet gewoon naar Github gaan

Dat snap ik ook niet echt.. zal wel gevalletje eigen eiland/infrastructuur zijn. Veel projecten worden ook op Github ontwikkeld ivm de veel betere workflow met PR's enzo. En dan met web_hooks naar Drupal.org ge-synced.

Er schijnt overigens wel gesproken te worden over een volledige migrate naar iets als github/gitlab, maar dat ligt minstens zo gevoelig als de switch naar OO code en TWIG templates.

[Cartman!]

kwaakvaak_v2 schreef op maandag 09 februari 2015 @ 13:46:
nodes ja, maar dat is de basis van het systeem. Alles is een entity..

Dat vind ik zeer onpraktisch.

Hooks, niet helemaal waar, de meeste hooks gaan uiteindelijk een keer naar event system

Uiteindelijk ja, maar dat is nu nog niet. Als ik nu de huidige Drupal 8 build pak vind ik overal hooks terug wat mij erg 2008 aandoet.

Maar dat kan nog even duren, voordeel is dat het nu onder semver gaat gebeuren en dat tussentijdse releases sneller kunnen komen dan de 4+ jaar die het nu duurt per major.

En code, knock your self silly : http://cgit.drupalcode.org/drupal/tree/?h=8.0.x

Ik bedoelde meer iets als Symfony Docs & Cook Books waar je gewoon onderwerpen hebt met uitleg over concepten ondersteund met code. De lappen tekst die op de Drupal site staan zonder code nodigen mij niet uit om het te gaan lezen.

Verder vind ik bovenstaande er enorm gaar uitzien...zet het lekker op GitHub neer.

Bottomline: het blijft outdated aanvoelen allemaal.

[Barryvdh]

kwaakvaak_v2 schreef op maandag 09 februari 2015 @ 13:57:
[...]

Er schijnt overigens wel gesproken te worden over een volledige migrate naar iets als github/gitlab, maar dat ligt minstens zo gevoelig als de switch naar OO code en TWIG templates.

Ja hier: https://groups.drupal.org/node/313068
Heb ook keer gereageerd, maar is al anderhalf jaar oud, zonder echte conclusie. Blijven vooral wat mensen die het er niet mee eens zijn.

[kwaakvaak_v2]

Barryvdh schreef op maandag 09 februari 2015 @ 14:28:
[...]

Ja hier: https://groups.drupal.org/node/313068
Heb ook keer gereageerd, maar is al anderhalf jaar oud, zonder echte conclusie. Blijven vooral wat mensen die het er niet mee eens zijn.

Dat is het grootste probleem, teveel dinosauriërs die al sinds V1 meegaan en bang zijn voor alles wat nieuw is. De hele migratie van SVN -> GIT heeft mensen weggejaagd omdat ze niet met GIT wilde leren werken. Als nu de flow van patches ipv pull requests ook los gelaten worden jaagt dat ook weer mensen weg.

Persoonlijk denk ik dat, dat juist geen probleem is. Als project wil je toch graag developers die open staan voor de toekomst ipv angstvallig vasthouden aan iets wat ze kennen..

Maar goed... we wijken af van de oorspronkelijke vraag Maar dit is één van de punten waar ik zie dat bijv. Symfony, maar ook andere PHP developers kansen kunnen creëren. Als ze de energie er voor hebben tenminste. Het hele TWIG verhaal heeft ruim 2 jaar geduurd, naar mijn eerste Frontend United talk, in dezelfde week dat er in US of A ook gesproken werd over TWIG ipv PHP Template.. En zie daar... D8 komt met een nieuw systeem, waarin alles wat aan de voorkant gebeurt door TWIG wordt afgehandeld ipv het woud van theme functies in D7.

[jeremyk]

Wat leuk dat er hier mensen een discussie hebben over Symfony2 en Drupal 8. Zelf ben ik een ervaren Symfony 2 gebruiker (sinds beta) en heb er al meerdere (grote) websites mee gemaakt.

Recentelijk ben ik opzoek geweest hoe het beste een pagina systeem in SF2 te krijgen. Ben niet echt van plan om mijn eigen bundles te onderhouden. Uiteindelijk ga ik denk ik kiezen voor Symfony CMF i.c.m. met Sonata AdminBundle (voor nu).

Maar leuker leek mij misschien om Drupal 8 alle CMS functionaliteit te laten afhandelen en daarnaast me eigen Symfony 2 routes te hebben voor custom functionaliteit.

Mijn vraag als SF2 gebruiker op zo'n cursus zou zijn: Kan ik Drupal 8 en Symfony 2 voor effectief voor één website gebruiken en tips hiervoor.

En een 2de, is er een wereld voor te stellen om Doctrine ORM entities te managen in Drupal 8.

[ Voor 6% gewijzigd door jeremyk op 24-03-2015 21:13 ]

[Cartman!]

Gezien de TS niet meer heeft gereageerd denk ik niet dat hij nog iets gaat doen met onze reacties

[kwaakvaak_v2]

jeremyk schreef op dinsdag 24 maart 2015 @ 21:11:
Wat leuk dat er hier mensen een discussie hebben over Symfony2 en Drupal 8. Zelf ben ik een ervaren Symfony 2 gebruiker (sinds beta) en heb er al meerdere (grote) websites mee gemaakt.


Maar leuker leek mij misschien om Drupal 8 alle CMS functionaliteit te laten afhandelen en daarnaast me eigen Symfony 2 routes te hebben voor custom functionaliteit.

Mijn vraag als SF2 gebruiker op zo'n cursus zou zijn: Kan ik Drupal 8 en Symfony 2 voor effectief voor één website gebruiken en tips hiervoor.

En een 2de, is er een wereld voor te stellen om Doctrine ORM entities te managen in Drupal 8.

1. Drupal 8 gebruikt Symfony CMF als router component, dus dat gaat in principe al. Drupal noemt het alleen menu items ipv routes. En in principe kun je daar dus als je functionaliteit aanhangen.

2. Gaat um niet worden, Drupal komt met zijn eigen AR achtig patroon genaamd Entity API. En heel eerlijk gezegd, maakt het niet zo heel veel uit of je nu DQL of EFQ moet schrijven, het gaat om de abstractie. Je kunt met de laatste beta van D8 al zonder problemen je storage laag vervangen van MySQL naar MongoDB als je dat zou willen. Of zelfs door elkaar gebruiken. Grote verschil is dat Drupal meer een traditioneel AR patroon heeft.


Je moet de bridge tussen Drupal 8 en Symfony2 meer zien op het niveau van components, zoals de routing, container etc. Niet op het niveau van het Symfony full stack framework. Ze gebruiken op die manier ook components uit Doctrine (yaml en annotations) en volgens mij nog paar dingen van ZF2.

Waar het meer om gaat is, dat Drupal van hun not invented here ideeën zijn afgestapt, en hun karakteristieke eigenschappen van het CMF/CMS hebben behouden, maar een heel groot deel van de onderliggende code hebben vervangen voor community components.