[Symfony][SF2][Symfony2]Organizacja bundli, sf2, symfony2, bundle Opcje

[Marys91]

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?

[basso]

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ę (IMG:style_emoticons/default/smile.gif) .
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

Ten post edytował basso 21.12.2012, 09:46:49

[ohm]

(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.

[adbacz]

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.

[d3ut3r]

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.

[Marys91]

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?

[adbacz]

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.

[Marys91]

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 (IMG:style_emoticons/default/tongue.gif)

Ten post edytował Marys91 27.12.2012, 18:23:26

[basso]

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 (IMG:style_emoticons/default/smile.gif)



Ten post edytował basso 26.04.2013, 13:17:26

[webmaniak]

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:)?

Ten post edytował webmaniak 30.04.2013, 08:11:40

[basso]

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 (IMG:style_emoticons/default/wink.gif)

[webmaniak]

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 (IMG:style_emoticons/default/smile.gif) 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).

[m44]

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.

[webmaniak]

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 (IMG:style_emoticons/default/sad.gif) Może ktoś napisać czy ma podobny problem?

[pyro]

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...

Ten post edytował pyro 26.05.2013, 12:57:02

[webmaniak]

Ok, dziękuję za odpowiedź. Zadam pomocnicze pytanie żeby zrozumieć Twoją wypowiedź (IMG:style_emoticons/default/smile.gif) 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 (IMG:style_emoticons/default/smile.gif) ?

[basso]

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...

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 (IMG:style_emoticons/default/smile.gif) => 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 (IMG:style_emoticons/default/smile.gif)

Ten post edytował basso 28.05.2013, 14:59:36

[webmaniak]

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.

Masz na myśli to:

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 (IMG:style_emoticons/default/smile.gif)

?

[basso]

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 (IMG:style_emoticons/default/smile.gif)



Ten post edytował basso 29.05.2013, 12:04:10

[webmaniak]

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.