Witam,
w ramach treningu z SF2 próbuje wyskorbać mały systemik do zarządzania stroną. Jednak po rozpoczęciu prac i już napisaniu trochę rzeczy zaczeła zastanawiać mnie jedna sprawa. Mianowicie chodzi o strukturę budli. Przykładowo załóżmy sobie, że mamy jakiś CMS, który ma Backend i Frontend. Teraz w każdej z tych części będą obsługiwane artykuły, które mogą być umieszczane w kategoriach. Pytanie jak teraz po tworzyć bundle do tego?

Mam takich aprę opcji:
1.
/MyCMSBundle
-/ForntendBundle
-/BackendBundle

2.
/MyCMSBundle
-/ForntendBundle
-/ArticleBundle
-/CategoryBundle
-/BackendBundle
-/ArticleBundle
-/CategoryBundle

3.
/FrontEndBundle
/BackendBundle

Ewentualnie jakieś inne propozycje?

Ja bym to widział tak. Budujesz sobie swojego CMS-a. W zależności od tego co chce klient dorzucasz mu odpowiednie bundle.
Front dobrze aby był całkowicie nowym bytem. Też myślałem o tym kurcze jak to zorganizować.

Poniższa struktura. W razie dorobienia sobie np. bundle Newslettera po prostu wrzucasz sobie go do swojego CMS. I nie mieszasz to z frontem. Jest to Twój CMS i jest on niezależnym bytem nie mieszającym w to front. Po za tym, jeśli miałbyś FRONT w /MyCMSBudnle to przy bardzo dużym obciążeniu... twój CMS też by to pewno odczuł bo byłby w jednej przestrzeni. => może się mylę, ale też próbuje zbudować CMS i tak to sobie tłumaczę .
Może ktoś już budował coś większego i się podzieli doświadczeniem.

/MyCMSBundle
-/ArticleBundle
-/CategoryBundle
-/NewsBundle
-/PageBundle

dorobieś sobie nowe bundle, albo klient chce bo kupił wersję rozszerzoną
-/NewsletterBundle
-/GaleriaZdjęćBundle
-/LogiBundle


A TUTAJ NOWY MODUŁ (nowa przestrzeń nazw)
/MyFrontCMSBundle
-/MyFront1CMSBundle
-/MyFront2CMSBundle

(Moja opinia na ten temat) Bundle to bundle, CMS to CMS, więc CMSBundle, reszte załatwiają serwisy, controllery itp. Jak masz zamiar dodać nową niezależną funkcjonalność, wtedy tworzysz nowy bundle. Wg mnie, nie ma sensu rozgrzebywać tego na frontend i backend. Bundlem może być cms, forum, panel admina, itp.

Ja natomiast zrobiłbym to w ten sposób. Nie mieszać bundli Backend i Front end w jednym katalogu, bo to porażka jakaś jest. Zrobiłbym po prostu dwa katalogi, w których trzymałbym osobno grupy tych bundli. Dojście do tych katalogów rozgraniczył albo na poziomie HTACCESS albo na poziomie subdomeny - to już zależy od Ciebie.

Potem każdy element serwisu powinien być osobnym bundlem w jednym z tych dwóch katalogów. Na przykład:
1. Artykuły, kategorie artykułów, jakies tagi i coś tam jeszcze;
2. Newsletter
3. Forum - TO jako całość, wiem, że to duży element ale nie da się rozdzielić forum na kilka części.
4. Uzytkownicy

Każdy z tych elementów będzie miał swojego odpowiednika we Frontendzie i Backendzie. Wiem, że to trochę dużo, ale wierzcie mi, takie rozdzielenie daje tylko same plusy. Jeśli od samego początku sobie dobrze to podzielisz to później będzie Ci to łatwiej edytować.

My w autorsim CMSie tak właśnie robimy. Mimo, że nie jest on pisany z użyciem żadnego frameworka, tylko na jego potrzeby trzeba było napisać coś nowego, ale i tak większość rzeczy jest tak właśnie podzielona. Elementy dla administratorów i redaktorów powinny być zupełnie niewidoczne dla użytkownika końcowego. Wiem, że to załatwia sprawa autoryzacji i logowania, ale i tak warto to podzielić.

Takie jest przynajmniej moje zdanie, takie zostało wdrożone w życie i od dawna się sprawdza beż żadnych kłopotów. Ale pamiętaj, to że inni robią tak a nie inaczej to nie znaczy, że masz robić tak samo. Możesz się wzorować na innych, ale pamiętaj, że to Twoja aplikacja, powinna działać tak, żeby Tobie się pracowało najlepiej i najszybciej na niej.

Organizacja Bundli to zawsze sporny temat, wydaje mi się że nie ma tutaj złotej reguły. Osobiście staram się dzielić bundle zgodnie z faktem czy później będę mógł go wykorzystać czy też nie, dlatego zazwyczaj mam coś w rodzaju:

FrontBundle - funkcjonalność specyficzna dla danego projektu która prawie nigdy nie zostanie ponownie wykorzystana, jednocześnie tutaj znajduje się główny layout który jest rozszerzany, szablony wiadomości e-mail itd.
AdminBundle - podobnie jak FrontBundle z tym że dotyczy to panelu administratora.

i następnie mam Bundle, które najczęściej powtarzają się we wszystkich projektach np:

ContactBundle
UserBundle
ArticleBundle
MessagesBundle

W takim przykładowym ArticleBundle mam kontrolery, które są przeznaczone zarówno dla frontu jak i panelu administracyjnego (edycja / dodawanie / usuwanie artykułów itp.)

Czy jest to prawidłowe podejście ? nie mam pojęcia, dla mnie jest ono po prostu wygodne.

Dzięki za podpowiedzi. Jakoś postaram się to ogarnąć., zobaczymy jak to będzie.

Jeszcze mam problem z ogarnięciem dodawania rozszerzeń, miałem początkowo pomysł dodawania tego w formie bundla i pytanie czy da się to tak zrobić i czy to jest dobra praktyka, czy lepiej zrobić to w odzielnym bundle, który będzie obsługiwał rozszerzenia?

Zależy co to mają być za rozszerzenia i co mają robić. Napisz coś na temat przykładowego to będzie lepiej nam odpowiedzieć na to pytanie.

Oki, przykladowo może być np. katalog produktów od admina dodajemy katalog produktów (kategorie, produkty, opisy zdjęcia...) i do tego chcę utworzyć kontroller, routing i oczywiście baza danych jakieś entity. Oczywiście to wszystko już byłoby napisane. Instalacja czy dodawanie polegałoby np. na uploadzie zip czy rar, który by się rozpakowywła w odpowiednim miejscu i dodanie do menu kolejnej pozycji. Trochę jak w joomla.

Chyba, że stworze sobie szkielet takiej podstawy gdzieś sobie to zapisze i jak będę potrzebował do czegoś to rozbuduje to np. o kolejnego bundla.

Czasami wydaje mi się, że prościej byłoby napisać wszystko od zera

Co sądzicie o takim rozwiązaniu=> bo już nie wiem jak to zrobić

Dla admina myślę zrobić coś takiego.
Czyli oddzielna przesterzeń nazw dla całego Backendu. Będą tam tylko i wyłącznie bundle dla Admina. Czy to CMS czy to wywołania CRONOWSKIE, czy może coś jeszcze.
Taki pakiecik będę mógł sobie przenieść gdzie będę chciał i nie będzie on związany z żadnym projektem.
Po za tym dla backendu mogę sobie robić różna pakiety dla klienta. Wtedy zakładając nowy projekt, kopiuje sobie swój backend z odpowiednim pakietem => nie mam nadmiarowaego kodu. Dobre to i złe no ale tak to wymyśliłem.

• Cms_V1Bundle - pakiet srerbny 10zł/ strony z treścią, logi, newsy
• Cms_V2Bundle - pakiet złoty 15zł/ strony z treścią, logi, newsy, galeria, musibox
• Cms_V3Bundle - pakiet platynowy 20zł/ strony z treścią, logi, newsy, galeria, musibox, RSS, Newsletter
• Cms_VSPECIALBundle - pakiet specjalny od 50zł/ strony z treścią, logi, newsy, galeria, musibox, RSS, Newsletter + specjalne zarządzanie na ŻYCZENIE

src/Backend/

• CmsBundle
• Cms_V1Bundle
• Cms_V2Bundle
• Cms_V3Bundle
• CmsCronBundle
• CmsSoapBundle

Teraz co z frontem? Nie wiem czy nazwać to:
src/Frontend/

• SportowiecplBundle

Czy może:
src/Sportowiecpl/

• FrontendBundle
• CronBundle
• RssBundle

Wydaje mi się, że ta 2 opcja będzie lepsza jesli chodzi o front. Bo dla danej strony mogę mieć różne rzeczy w tym FRONT.

Macie może jeszcze jakieś inne rozwiazania. Pewno ktoś tu ma większe doświadczenia i wie z czym to się je najlepiej

Ponawiam pytanie z ostatniego posta, bo mnie również ciekawi jak można to rozwiązać. Podoba mi się rozwiązanie @basso z 2 postu, ale nie wiem czy będzie poprawne. Mógłby się ktoś wypowiedzieć jeszcze:)?

No ja tez nie wiem czy jest poprawne, pewno nikt nie będzie dokładnie wiedział czy jest to poprawne rozwiązanie, bo każdy ma swoje wymagania i rozplanowania i w różny sposób to gryzie. Dobrze by było, jakby ktoś doświadczony, rzucił na to okiem i doradził, bądź jakieś zalety i wady stosowania różnych rozwiązań. Ja już zacząłem robić jak pisałem wyżej, na razie jest rarytas. Zobaczymy jak to się sprawdzi w życiu ... pewno wtedy sobie sam doradzę bo już będę wiedział co i jak

Muszą być jakieś standardy, choćby takie które powiedzą jak nie może być. Twój sposób mi się podoba, bo łatwo można przenieść bundla z jednej aplikacji do drugiej. Przychylam się więc do prośby kolegi i proszę o opinię kogoś bardziej doświadczonego z symfony2 Tyle osób go poleca, ale jak człowiek ma dylemat to jakoś jest dużo mniej odpowiedzi ;/

Odświeżam temat, bo nadal nie wiem jak zorganizować aplikację. Wiem że każdy projekt jest inny, dlatego załóżmy że buduję CMS z taką funkcjonalnością:
-użytkownicy - wiadomo, dodawanie, usuwanie, edycja,
-grupy/uprawnienia,
-prosty system maili,
-ustawienia: treści, ogólne, użytkownika, strony,
-statystyki, backup i powiadomienia
-logi

Jak zorgranizować taką aplikację? Jak ją najfajniej podzielić na bundle? Chce zrozumieć logikę bundli(ich tworzenia).

Zobacz jak to robią inni. W Sonacie masz podział ze względu na funkcje. SonataUserBundle, SonataMediaBundle, SonataNotificationBundle. Wiem, że te paczki są słabo udokumentowane i można im wiele zarzucić, ale wydaje mi się, że taki podział jest logiczny.

Panowie, próba otworzenia strony symfony.com kończy się komunikate:
502 Bad Gateway
O co biega? Wg "google" wystarczy usunąć ciasteczka, ale mi to nie pomogło Może ktoś napisać czy ma podobny problem?

Cześć,

Strona symfony.com też mi nie wchodzi. Co do organizacji bundli - bundle to jakby wtyczka i według mnie tak należy je porządkować.

Przykładowo:
- UsersBundle
- MailerBundle
- PaymentBundle
- ShoppingCartBundle
- AdminBundle

itd, itp...

Ok, dziękuję za odpowiedź. Zadam pomocnicze pytanie żeby zrozumieć Twoją wypowiedź Na przykładzie pyroCMS - tam jest tak że mam np model users i w controllers jest kontroler dla usera i dla admina. Te bundle które wymieniłeś - rozumiem ich podział - wydaje się zgodne z tym co do tej pory przeczytałem - prócz ostatniego - modułu AdminBundle - masz tu na myśli umieszczanie do tego bundla kodu z pozostałych modułów? Czy on będzie tylko zbierał informacje - patrzę w repozytorium jak to wygląda w sonacie, ale mam wątpliwości.
Odnośnie strony symfony to była to chwilowa przerwa.
A tak w ogóle to czy Twoja nazwa użytkownika ma coś wspólnego z pyroCMS, czy to zbieg okoliczności ?

Robiłem tak => system tak puchł od ilości plików, a już miałem sporo napisane..., że wolałem to przerobić to na podane wyżej przeze mnie podejście.
Po drugie, no layout trzeba podłączać do każdego taki sam... aby widok był przyjemny...
Po trzecie... łączył ktoś ENTITY=> UserBundle z PaymentBunle z dwóch różnych BUNDLI ? No bo np. relacja N:N => Ja tak... udało się, ale jest to śmietnik programistyczny. Po za tym, przy generowaniu CRUDA trzeba bardzo uważać.

Nie polecam tego rozwiązania. Wolę dodać 1 kontroler niż całą masę plików z którego będę korzystał i tak tylko z 1 kontrolera

Masz na myśli to:

?

Tak , teraz mam przerobione na tą wersję którą zacytowałeś.
I jest świetnie, nie ma problemu z realacjami, bo niestety ale jak masz USERBUNDLE i GALLERYBUNDLE => no to musisz je połączyć realcją. A to są 2 oddzielne ciała... i zaczyna się jazda...
Po za tym, każdy pierdółek w oddzielnym Bundlu no to jest masa plików niepotrzebnie... bo i tak przeważnie się korzysta tylko z 1 kontrolera z tego BUndla

Czyli masz Backend osobno i frontend osobno? możesz to jeszcze raz opisać, bo w tym co ja zacytowałem są w sumie dwa rozwiązania... a wnioskuję że połączyłeś wszystko z front do bundla i z backendu do bundla.

Pozwolę się podpiąć do tematu, załóżmy, że mam tabelę w bazie, z które będą musiały korzystać dwa bundle, czy w takiej sytuacji bardziej wskazane jest tworzyć dwie encje (jedna na bundla) czy dwie, dla każdego bundla osobno?

pozdrawiam!

Ten pomysł wydaje mi się najlepszy, ale pytanie tylko jak najefektywniej ogarnąć routing?

Powiedzmy, że mam moduły, galeria i kontakt na razie, teraz pytanie czy lepiej routing zrobić w jednym miejscu to jest routing.yml czy w adnotacjach w każdym kontrolerze, który wykorzystuje dany moduł.

1) Wrzucam GalleryBundle do projektu i muszę w routing.yml dodać regułę powiedzmy
Route: /gallery
Controller: GalleryBundle:galleryController:index

2) Wrzucam GalleryBundle do projektu, w adnotacjach mam już zapisane @Route("/gallery"), więc tutaj nie muszę zmieniać tego już dalej, bo automatycznie jest wyłapywane, ale znowu z drugiej strony jak będę chciał mieć powiedzmy @Route("/galeria") lub "/kolekcja", "/portfolio", to za każdym razem muszę edytować kontrolery.

W przypadku pkt 1 mam wszystko w jednym miejscu i łatwiej jest coś zmienić.

Jakie jest wasze zdanie na ten temat?

Mam tak zrobione:

/Backend/

• CmsV1Bundle:
  
  • - ArtilceController
  • - PagesControler
  
  
• CmsV2Bundle:
  
  • - ArtilceController
  • - PagesControler
  • - GalleryController
  
  
• CmsV3Bundle:
  
  • - ArtilceController
  • - PagesControler
  • - GalleryController
  • - NewsletterController
  
  
• AuthBundle - funkcjonalność obowiązkowa dla strefy Backend (każdy Backend to posiada defaultowo)
• ACLBundle - rozszerzona obowiązkowa funkcjonalność dla strefy Backend (każdy Backend to posiada zamiast Auth , jeśli chce zarządzać użytkownikami)

/Frontend/

• www.ZycieNaGorocno.plBundle:
  
  • - ArtilceController
  • - PagesControler
  • - GalleryController
  
  
• www.BiegiKrakow.pllBundle:
  
  • - ArtilceController
  • - PagesControler
  • - GalleryController
  
  
• www.Kotek.plBundle:
  
  • - ArtilceController
  • - PagesControler
  • - GalleryController

Te moduły są przykładowe jeśli chodzi o Backend/Frontend

FRONTEND:
Każda nowa strona jest nowym Bundlem, zatem do 1 cmska podłączam sobie kilka frontów , no jak mi się tam tylko podoboba. To jest dobre, bo do 1 strony, możemy sobie przygotować kilka frontów (layoutów)


Jeśli ktoś chce robić w ten sposób (patrz poniżej): => to niech robi i potem opowie jak wrażenia z relacji pomiędzy Bundlami
Przykładowo:
- UsersBundle
- MailerBundle
- PaymentBundle
- ShoppingCartBundle
- AdminBundle
- GalleryBundle

Nie neguję tego... tylko nie polecam, bo ja mam coś takiego na lokalu. Problemy z routingiem, problemy z layotem.. no bo musi być w każdym bundlu ten sam LAYOUT, i problemy z relacjami w Entity.
Nie twierdzę, że moje rozwiązanie to PEREŁKA programistyczna... po prostu do tego doszedłem, że jest tak najwygodniej i najbardziej optymalnie. Jeśli ktoś widzi w tym jakieś błędy to chętnie przyjmę uwagi aby poprawić swój system. Cały czas się uczę SF2

Cześć. Ja używam właśnie takich adnotacji. Zero problemów z routingiem, zero problemów layoutem, widocznie coś źle robisz. Mało tego sami twórcy Symfony zalecają taki podział. Oczywiście to także zależy od projektu (bo jak ma być jakiś z 1000 bundli to jeszcze inaczej trzeba to jakoś zorganizować) no i trochę od gustu, bo podział plików ma tylko charakter porządkowy. Ale jak ktoś tu wspomniał w temacie wpychanie wszystko do jednego kontrolera to jakaś bzdura.

No ja miałem troszkę problemów i musiałem troszkę pokąbinować. Mój każdy kontroler to max hmmm 10 akcji. No przesadziłem... 8 sztuk A 5 kontrolerów to chyba jest mniej jak samych wpisów w KERNELU od ilościu bundli . No tak jak pisałeś/pisałaś wszystko może i zależy od projektu, albo może też od wygody/przyzwyczajenia. Ja jestem jednego zdania i kieruje się też definicją frameworka => Framework to pewien wzorzec programistyczny, który ma UŁATWIĆ i PRZYŚPIESZYĆ pracę, poprzez wprowadzenie, ładu,porządku i przejrzystości... i z tą przejrzystością jest tak, że jedni ją widzą inaczej, a drudzy inaczej Ale najważniejsze ma być to=> ma to ułatwiać , a nie, żeby ktoś się męczył i żyłował.

Pozdro

Czy w wersji 2.3 zmieniła się struktura folderów bundle? Poprzednio jak tworzyłem nowy bundle z konsoli to tworzyło mi katalog (dla wersji 2.1):


W tej chwili dodało jeszcze jeden poziom do folderów:


Po co tworzy ten dodatkowy folder "Bundle" - struktura z 2.1 była OK.

Co z konfiguracją poszczególnych bundli?

Załóżmy, że stworzę sobie GalleryBundle, który będzie domyślnie posiadał jakiś widok, ok. 3 zdjęć (chodzi tutaj o wstępne pokazanie działania).

Ale chciałbym do tego GalleryBundle stworzyć również jakiś plik konfiguracyjny (gallery_config.yml), który znajdowałby się w src/Project/GalleryBundle/Resources/config/... i zawierałby coś na wzór:



Oczywiście taki config byłby domyślnym, a w późniejszym etapie mógłby zostać nadpisany w app/config.yml.

Teraz pytanie do was. Jak do tego podejść?
Jak podzielić bundle, ale żeby każdy miał swój config?

Do tego podejść? Starasz się wpakować do configu to co powinno być w widoku, co ty w ogóle wyprawiasz?

Sam już do końca nie wiedziałem jak do tego wszystkiego podejść.

Masz na myśli zrobienie jakiegoś

{% set ... %} w widoku na jego początku, a później wykorzystywanie tego w dalszych częściach widoku?

Chciałem zapytać co sądzicie o następuącej organizacji bundli pod system CMS.

Chce oczywiście rozdzielić Frontend od Backendu.

Tworzę np Bundl'a:

ArticleBunndle/

następnie mamy Controller/ i tam utworzyć katalogi app/ (frontent) oraz admin/ (backend)
i w nich umieszczać odpowiednie kontrolery.
tak samo bym zrobił z widokami oraz assetami.
np. /Resources/css/ i w nich app/ oraz admin/

Routy tez bym rozdzielił w bundle'u na app/ oraz admin by w łatwy sposób nadać odpowiednie prefixy globalnie czyli dla frontendu brak a dla admina /admin

Servisy pozostawiłbym wspolne by zarówno korzystać z nich po stronie backendu jak i frontendu.

Miałbym też głowny np. MainBundle po ktorym dziedziczylyby Kontrolery bundli backendowych
oraz AppmainBundle dla frontul.

Uważacie że jest to dobre podejscie do tematu?

Pozdrawiam.

Organizacja bundli taka jak podał: d3ut3r Też wydaje mi się najlepsza.
Zawsze robię dwa bundle specyficzne dla projektu : AppBundle(panel) i FrontBundle




Wszystkie encje dla projektu trzymam w AppBundle i używam ich w FrontBundle. (bundle sa scisle ze sobo powiazane i nigdy nie bede uzywane osobno)

Co do twojego pytania i routingu:
Rozdzielem prefiksy osobne dla AppBundle i FrontBundle:

[PHP] pobierz, plaintext 
app:
    resource: "@VendorNameAppBundle/Controller"
    prefix: /admin
    type:     annotation
[PHP] pobierz, plaintext 

A więc używam annotacji w routingu. W praktyce tak wyszło, że zdecydowanie dla mnie użyteczniejsze są annotacje. Tworze nową akcję to odrazu też tworzę routing w jednym miejscu, nie musze wracać do globalnego pliku i tam tworzyć routingu.
Każde stworzenie akcji to jest napisanie akcji i modyfikacja pliku z routingiem. Po co ? tak szybko tworzę całość w jednym miejscu.

Generalnie chce zrobić tak jak d3ut3r
Dwa głowne Bundle do Frontu i Backendu.

i potem pozostałe Bundle jak np Artykuły czy Galerie, z tym że d3ut3r już nie rozdziela kontrolerów które są do backendu a które do frontendu a ja chcialbym je dodatkowo podzielić ze wzgledu na przejrzystość projektu.

Ok kumam o co ci chodzi.
Ale ja nie robię takich zależności i bundli osobncyh dla artykułów i galerii. Może trochę więcej pracy dla mnie.

Po prostu startowy Backend od którego zaczynam pracę na nowym projekcie ma już pewien zbiór encji: Article, Gallery itd. W zależności od projektu ewentualnie potem modyfikuję te encje, jeśli jest potrzeba.
Potem generuje cruda i już mam cały admin. A frontend i tak lda każdego projektu jest różny.

To już mam pewną koncepcję Dzięki za wsparcie.

Pierwotnie miałem plan by bundle robić wtedy jak coś większego się kroi.
Dla swojej apki chciałem zrobić:
- główny bundle na całą stronę
* kontrollery rozdzielać tak, że np. gdy wiemy, że na danej podstronnie nie będzie się dużo działo i nie jest ona jakoś sensownie połączona z innymi akcjami, pakujemy to do głównego kontrollera(np. strona 'o mnie', 'kontakt')
* jeśli wiemy, że będziemy mieli parę podstron, które logicznie są ze sobą powiązane, wtedy tworzymy dla nich kontroler czyli np 'profil' => 'moje_dane', 'profil' => 'zmien_haslo', 'profil' => 'zmien_dane' - kluczem jest kontroller, wartością akcja.
- bundle na panel admina i ten sam sposób działania co w głównym bundle'u

Logika byłaby zawarta w service container'ach.

Dosyć ciekawy jest pomysł na FrontEnd, BackEnd i tworzenie bundle dla każdej małej funkcjonalności, tylko do końca nie wiem jak to ma działać.

1) We FrontEndzie i Adminie mają znajdować się tylko same widoki i nie ma w nich żadnych kontrolerów, encji, formularzy itp.?
2) Pojedyncze mniejsze bundle mają kontrollery, formularze oraz encje i wszystkie odwołują się do widoków z frontendu lub admina?


Czyli np. mamy funkcjonalność dodawania komentarzy.
a) Mamy odzielny CommentsBundle
Mamy tam ładnie zdefiniowane kontrollery(tworzymy oddzielną akcję w kontrolerze do głównej strony i inną do działania w adminie), encje i formularze
c) we Frontendzie pakujemy widoki

Tak to rozumiem, o to miało mniej więcej chodzić?