Hva bør en bunt i Symfony2 representerer

stemmer
32

Dette kan være en åpenbar ting til deg, men - selv etter å ha lest gjennom en rekke håndbøker og blogger - jeg er fortsatt ikke sikker på hva bør en bunt i Symfony2 representerer i en webside. Og det er vanskelig å gjette det fra de enkle demo applikasjoner.

For eksempel: Jeg har et område som er delt inn i to deler (en er bare en andre domenet som example.comog en annen er dom2.example.com). Hver av disse to delene har noen deler av sin egen - noen ganger samme (som nyheter) noen ganger forskjellige.

Hva ville den korrekte gjengivelse av dette i symfony2? Bør jeg ha

  • en MySite\site1og MySite\site2bunte og gjøre de forskjellige seksjonene via ulike kontrollere, eller
  • bunter Site1\Newsog Site2\News, eller
  • bunter MySite\Site1Newsog MySite\Site2Newsetc.

... eller får jeg alt galt på dette?

Publisert på 24/04/2011 klokken 13:28
kilden bruker
På andre språk...                            


3 svar

stemmer
15

Jeg er også ny på Symfony og vil følge resultatene av dette spørsmålet med interesse, men for hva det er verdt, min ta på det er:

En bunt er nettopp det: en gruppe filer, eiendeler, PHP klasser og metoder, tester osv Logikken i grupperingen kan være noe du liker. I noen tilfeller er det veldig klart hva grupperingen er og hvorfor det er blitt gjort - for eksempel hvis jeg skrev en blogg system for Symfony2 og ønsket å slippe det, jeg ville gjøre det til en bunt. Det er den slags eksempel brukes mest i dokumentasjonen.

Men du vil også bruke pakker for alt du ønsket å slippe så en liten funksjon. Si for eksempel, denne pakken som skaper standard ruter for alle dine kontrollere. Det er ikke en fullt utviklet plugin / funksjon som en blogg eller forum, men det er en bit av koden at jeg enkelt kan importere inn i prosjektet mitt, det holder helt atskilt fra alt annet, er det en bunt.

Til slutt vil du også bruke bunter internt i prosjektet, i absolutt noen måte som gir mening for deg.


Min ta på din situasjon:

Fort og lett:

  • MySite\MyCode - får jobben gjort, og kanskje du ikke har noen logisk måte å bryte opp koden du skal skrive.

Hvis det er noen flere unike funksjoner mellom de to stedene, og du ønsker å skille dem ut for klarhet:

  • MySite\SharedFeatures
  • MySite\Site1Features
  • MySite\Site2Features

Hvis du virkelig liker alt på sin plass, eller hvis du har et komplekst prosjekt, kanskje:

  • MySite\MySiteMain (Felles funksjoner og catch-all miscellany som ikke fortjener sin egen pakke)
  • MySite\News
  • MySite\Site1FeatureSomethingOrOther
  • MySite\Site2FeatureSomethingOrOther

Jeg tror definitivt du ønsker å holde seg til logiske grupper med kode - så jeg tror ditt eksempel "bunter site1 \ Nyheter og Site2 \ News" og "Mittnettsted \ Site1News og Mittnettsted \ Site2News" ikke ville være den beste veien å gå. Site1 og Site2 er implementasjoner, så gjør en separat pakke for hvert område nyheter side synes å være mot sin hensikt for meg; du ønsker å lage en nyhetselementet og bygge den kan brukes på to forskjellige måter.

Som for to-domener spørsmålet, kan du enten peke begge domenene på den samme koden, og test i koden for hva domenet er blitt bedt om, eller du kan sjekke ut to kopier av den samme koden og endre konfigurasjonsfilene litt (dette ikke nødvendigvis bryter ideen om tØRR fordi du fortsatt redigere koden på ett sted, deretter oppdatere begge kopier.)

Svarte 22/05/2011 kl. 07:36
kilden bruker

stemmer
11

Slik jeg forstår en bunt er at det ligner på det CMS som f.eks Typo3 eller Drupal kaller en "plugin". Så det burde være ideelt sett selvforsynt og skrevet på en måte at det kan brukes på andre prosjekter også.

For eksempel i ditt tilfelle ville jeg lage en "staticHtmlBundle" som inneholder alle de statiske sidene på nettstedet ditt, fordelt innenfra ved site.com og dom2.site.com.

Da ville jeg lage en "newsBundle" som inneholder alle nyhetsartikler, kanskje til og med database-drevet med litt admin-delen der du kan redigere dem og tilordne dem til ulike kanaler (i ditt tilfelle som er site.com, dom2. site.com). En statisk side innenfra staticHtmlBundle vil kalle newsBundle og vise data (som for eksempel en listevisning av nyhetene eller en detailView og så videre).

Hvis du holde alt som abstrakt og gjenbrukbare som mulig så du kan selv publisere newsBunde i Symfony 2 Bundle depot og dele den med fellesskapet!

Svarte 24/04/2011 kl. 14:25
kilden bruker

stemmer
1

Slik jeg oppfatter Symfony2 bunter er at de er å gi et modulært system som lar deg ikke bare forlenge og overstyre php kode, men også noen ressurser de kan eller ikke kan omfatte.

Når det er sagt, anser du har en API, og du ønsker å overføre et objekt.
Hvordan ville du gjøre det?

Selvfølgelig kan du gjøre det manuelt, men ville det ikke vært fint om Symfony kan gjøre det for deg?

Min måte å gjøre dette vil inkludere 3 bunter, JMSSerializerBundle og FosRestBundle .

  1. En bunt for klientsiden - MyCompany/ClientBundle
  2. En bunt for serversiden - MyCompany/ServerBundle
  3. En bunt bolig alle dataoverførings stedene jeg ønsker å være i stand til å overføre - MyCompany/CommonBundle.

Inni mitt MyCompany/CommonBundlejeg ville ha de klassene jeg vil bruke for min dataoverføring objekter sammen med serialisering regler jeg måtte gi JMSSerializerBundlemed. De kan være i form av XML, YML eller php merknader.

Når du har et objekt fylt opp med data, kan du bare bruke returnog FosRestBundleville serial det for deg. Serialisering vil avhenge av ruting, slik at du kan ha objektet serialisert i XML for ett system og i JSON for en annen. Hovedpoenget er at du har ulike serialisering formater og versjons du kan bruke på senere tidspunkt.

På klientsiden, kan du bruke enkle param omformer å konvertere mottatte JSON eller XML til et objekt rett i kontrolleren uten ekstra stresset. Du kan også skrive inn noen valideringsregler, slik at du kan kontrollere om objektet er befolket som du forventer at det skal være.

I mitt eksempel MyCompany/CommonBundlehar gjenstander som skulle brukes av flere programmer, og vil være identiske. Å ha det som en egen pakke hjelper deg å unngå kode duplisering og gjør langsiktig vedlikehold mye enklere.

Jeg håper jeg klarte å forklare dette. Noen spørsmål?
Spør i kommentarfeltet. Vil oppdatere svaret tilsvarende.

Svarte 30/12/2015 kl. 18:33
kilden bruker

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more