Wybór Frameworka. Opcje

[LBO]

z grubsza chodzi chyba o to ze kupujecie soft i go przerabiacie? to co to ma do frameworkow?

i że chyba kupują za 500,- a sprzedają za 5 000,-


Czy jakoś tak :]

[athabus]

Ja zdaje się zrozumiałem co chciał kolega powiedzieć, ale emp chyba nie rozróżnia frameworka od gotowego oprogramowania. Co za różnica czy oprogramowanie jest tworzone na podstawie frameworka czy pisane od podstaw? W sensie "dla klienta" oczywiście? Przecież używanie frameworka nei polega na przerabianiu tego samego softu dla 20 różnych klientów... Framework ma "tylko" automatyzować powtarzalne zadania.

[mike]

Dobra już nie ma co karmić trolla. Koleś widać, że nie ma zielonego pojęcia co jest framework i jakie jest jego zastosowanie.
Choć z drugiej strony podziwiam determinację ludzi, którzy strugają swój własny młotek jak mają zamiar wbić gwoździa.

Żeby ta dyskusja wróciła do odpowiedniego, wyższego poziomu sugeruję pominąć wypowiedzi ~emp i nie odpisywać na nie. Część ludzi po prostu nie jest reformowalna.

[phpion]

@athlabus:
Fakt, stworzyć aplikację na pewno można szybciej przy pomocy Symfony (generator modeli, generator admina etc.). Problemy jednak zaczynają się w momencie gdy trzeba coś zmienić (np. dodać nowe pole do tabeli, które dodatkowo będzie w relacji z inną tabelą) lub zmienić wygląd admina. Wszystko jest oczywiście możliwe, tego nie neguję, jednak dla mnie było to bardzo upierdliwe. Może źle szukałem ale nie znalazłem w Internecie informacji w jaki sposób korzystać z widoków PostgreSQL. Nie podoba mi się również to, że pola w tabeli w bazie danych są uniwersalne tj. takie, które są poprawnie interpretowane w najpopularniejszych silnikach baz danych (ale to już nie wina Symfony tylko samego Propela). Pisząc system pod PostgreSQL chcę w pełni wykorzystyać listę typów danych, jakie oferuje ta baza. Co tam jeszcze... konfiguracja w *.yml. No dobra, fajnie, ale często miałem problem typu "!@#$% jak to zapisać w YML?". M.in. z tych właśnie powodów odszedłem od Symfony - za dużo kombinowania jak dla mnie.
Jeżeli dobrze Ci się kodowało w CI to zapewniam Cię, że w K będzie Ci się kodowało jeszcze przyjemniej. Wybór jednak należy do Ciebie, my możemy jedynie wyrazić nasze prywatne zdanie.

[athabus]

@phpion
Hehe tu właśnie dochodzi kwestia gustów. Każdy z nas ma inne oczekiwania do frameworka. Ja zrezygnowałem z CI z powodu kiepskiej obiektowości (wiem, że Kohana pod tym względme jest dużo lepsza) oraz ogólnie dużej prostoty (dużo rzeczy trzeba było sobie samemu dorobić). W Symfony cenię to, że 95% standardowych rzeczy mam "out of the box" i "ready to use". Wiąże się to też z pewnymi ograniczeniami - np. wspomniane przez Ciebie wykorzystanie Propela jako ORM. Widoki co prawda Propel wspiera, ale fakt faktem, że abstrakcja wymusza zrezygnowania z opcji niestandardowych, jak np. dodatkowe typu pól w Postgresie. Można oczywiście zrezygnować z Propela i pisać wszystko samemu, ale wtedy traci się wiele udogodnień, które oferuje w Symfony.
Symfony ma też ten "minus", że wymaga znajomości/douczenia się pewnych zagadnień typu Prototype, Propel, subframework do formularzy czy konstrukcja yml - wynika to z tego, że Symfony wykorzystuje wiele komponentów napisanych przez kogoś innego. Jest to z jednej strony plus (bardziej dojrzałe i przetestowane rozwiązania), ale z drugiej strony wymaga większego wkładu w naukę na początku aby móc wykorzystać 100% możliwości.

Ogólnie jednak powiem Ci, że testowałem 3 frameworki i w każdym dopisywałem sobie pewne "skróty" i dodatki. Po przerzuceniu się na Symfony okazało się, że tam już wszystkie te rzeczy były i to w zasadzie miały podobne api do tego co ja napisałem. Można więc powiedzieć, że w Symfony jest tok myślenia jaki ja preferuję. Teraz gdy powoli przerzucam się na Symfony 1.2 widzę, że dodano tam jeszcze więcej tego typu umilaczy. Ty masz pewnie podobnie w Kohanej.

[michalg]

@athlabus:
Problemy jednak zaczynają się w momencie gdy trzeba coś zmienić (np. dodać nowe pole do tabeli, które dodatkowo będzie w relacji z inną tabelą) lub zmienić wygląd admina. Wszystko jest oczywiście możliwe, tego nie neguję, jednak dla mnie było to bardzo upierdliwe. Może źle szukałem ale nie znalazłem w Internecie informacji w jaki sposób korzystać z widoków PostgreSQL. Nie podoba mi się również to, że pola w tabeli w bazie danych są uniwersalne tj. takie, które są poprawnie interpretowane w najpopularniejszych silnikach baz danych (ale to już nie wina Symfony tylko samego Propela). Pisząc system pod PostgreSQL chcę w pełni wykorzystyać listę typów danych, jakie oferuje ta baza.

No niestety, taka jest cena abstrakcji bazy danych. Ale przecież nie musisz korzystać z propela przy pisaniu projektu pod symfony - zawsze możesz korzystać bezpośrednio z sqli.

Jeżeli chodzi o możliwość wykorzystania dodatkowych typów z psql przy użyciu ORM, to *teoretycznie* mógłbyś tworzyć strukturę bazy za pomocą ręcznie pisanego DDLa zamiast generowanego przez ORM.

[phpion]

No niestety, taka jest cena abstrakcji bazy danych. Ale przecież nie musisz korzystać z propela przy pisaniu projektu pod symfony - zawsze możesz korzystać bezpośrednio z sqli.

No coś Ty. W Kohana również mam abstrację bazy danych i nie mam żadnych wyżej opisanych problemów. Korzystanie bezpośrednio z raw SQL? W takim razie po co mi "dobrodziejstwa" Propela?

Jeżeli chodzi o możliwość wykorzystania dodatkowych typów z psql przy użyciu ORM, to *teoretycznie* mógłbyś tworzyć strukturę bazy za pomocą ręcznie pisanego DDLa zamiast generowanego przez ORM.

No tak, tylko znowu jesteśmy w punkcie opisanym powyżej: po co nam w takim wypadku cały Propel? W tym momencie staje się on przeszkodą niż ułatwieniem.

[michalg]

No coś Ty. W Kohana również mam abstrację bazy danych i nie mam żadnych wyżej opisanych problemów. Korzystanie bezpośrednio z raw SQL? W takim razie po co mi "dobrodziejstwa" Propela?


No tak, tylko znowu jesteśmy w punkcie opisanym powyżej: po co nam w takim wypadku cały Propel? W tym momencie staje się on przeszkodą niż ułatwieniem.

To jak to wygląda w Kohana? Możesz to pokrótce opisać, bo szczerze mówiąc nie znam tego, a jestem ciekaw. Chodzi mi o etap przygotowania schematu bazy danych oraz dostępu. I czy w Kohanie masz abstrakcję na obu tych etapach?

[phpion]

Nie, w K tworzysz bazę danych "ręcznie" (co dla mnie jest dużą zaletą), natomiast cała komunikacja z bazą danych realizowana jest z użyciem abstrakcji.

[michalg]

Nie, w K tworzysz bazę danych "ręcznie" (co dla mnie jest dużą zaletą), natomiast cała komunikacja z bazą danych realizowana jest z użyciem abstrakcji.

To w takim razie chyba się nie zrozumieliśmy - pisząc abstrakcja miałem na myśli również abstrakcję definiowania schematu bazy oraz budowania sqli. To dają rozwiązania typu propel i doctrine. Tego Ci nie da np PDO (chyba, że się mylę). Oczywiście nie mówię, że jest to zaleta - bo sam się męczyłem, jak za pomocą doctrina napisać trochę bardziej skomplikowane zapytanie i skończyło się na bezpośrednim wykorzystaniu PDO. Niestety, nie ma rozwiązań idealnych.

A czym Twoje rozwiązanie się różni od tego co napisałem wcześniej?

Ale przecież nie musisz korzystać z propela przy pisaniu projektu pod symfony - zawsze możesz korzystać bezpośrednio z sqli.

[phpion]

To w takim razie chyba się nie zrozumieliśmy

I chyba dalej się nie rozumiemy Kohana nie posiada generatora bazy danych na podstawie napisanego schematu (schema.yml). Cały schemat (tabele, kolumny, relacje itd.) tworzysz ręcznie. Natomiast jeśli chodzi o samą komunikację z bazą danych to K posiada warstwę abstrakcji bazy danych (MsSQL, MySQL, MySQLi, PostgreSQL). Dodatkowo (i chyba o to Ci chodzi) posiada tzw. query builder czyli narzędzie służące do dynamicznego tworzenia zapytań:
http://docs.kohanaphp.com/libraries/database/builder
Można również korzystać z bezpośrednich zapytań do bazy.

[michalg]

I chyba dalej się nie rozumiemy Kohana nie posiada generatora bazy danych na podstawie napisanego schematu (schema.yml). Cały schemat (tabele, kolumny, relacje itd.) tworzysz ręcznie.

Ok, to rozumiem - piszesz ręcznie sqla z create table itp. Ale i tak tracisz przy tym abstrakcję, bo piszesz pod konkretną bazę danych. Za to możesz skorzystać z rzeczy typowych np tylko dla postgresa.

Natomiast jeśli chodzi o samą komunikację z bazą danych to K posiada warstwę abstrakcji bazy danych (MsSQL, MySQL, MySQLi, PostgreSQL).

Czyli coś podobnego, co daje PDO. Czy ta abstrakcja w K korzysta z PDO czy to jest coś zupełnie innego?

Dodatkowo (i chyba o to Ci chodzi) posiada tzw. query builder czyli narzędzie służące do dynamicznego tworzenia zapytań:
http://docs.kohanaphp.com/libraries/database/builder

Ok, czyli to jest jedyny element, którego nie masz w symfony jeśli decydujesz się na rezygnację z któregoś z ORM.

Jednym słowem - punkty 1 i 2 można osiągnąć w symfony, jeżeli zdecydowałbyś się nie używać propela (w sf 1.2 jest to nawet jako plugin, który można wyłączyć). Jedyne czego nie ma, to ten query builder.

Być może w kolejnych wersjach symfony pojawi się takie "lekkie" rozwiązanie wspomagające dostęp do bazy danych, lub ktoś wypuści jakiś plugin.

A propo kolejnych wersji - nie wiem, na ile ta strona zawiera prawdziwe oraz aktualne informacje
http://trac.symfony-project.org/wiki/Symfony2Discussion

ale jest tam coś takiego:
Orm:

• Propel 2.0
• ezPDO
• Doctrine
• "home made"
• Zend_db extension

[nrm]

Czy ta abstrakcja w K korzysta z PDO czy to jest coś zupełnie innego?

nie korzysta. typowy ActiveRecord. ORM jako osobna biblioteka.

[mike]

Ostatnio oglądałem sobie to całe Kochana Chyba nawet skuszę się na kilka "stronek" w tym, ale jak znajdę chwilkę czasu na przeczytanie dokumentacji, która pozostawia wiele do życzenia (wróć, jest po prostu dardzo słaba) i jak podłączę tam Propela 1.3.

[nrm]

jezu. jak @Mike zrobi cos w Kohanie to znaczy że świat stanął na głowie

ps. dokumentacja nie nadąża za zmianami ale taka fatalna to nie jest. chyba

[phpion]

dokumentacja nie nadąża za zmianami ale taka fatalna to nie jest. chyba

Też jestem zdania, że nie jest najgorsza. Powiedziałbym wręcz inaczej: jest wystarczająca. Jeżeli mam jakieś wątpliwości to sobie przeglądam źródła klas i w bardzo krótkim czasie jestem w stanie połapać się co i jak działa (w przeciwieństwie do Symfony, a o Zend Framework już nie wspomnę hehehe).

// Edit:
Swoją drogą: dyskusja chyba zeszła nieco z tematu więc może lepiej byłoby przenieść niektóre posty do Wybór Frameworka?

Ten post edytował phpion 9.12.2008, 20:06:14

[kwiateusz]

j.w. cześć postów została wydzielona z Temat: [Symfony]Symfony_a_duze_projekty

[nrm]

można sobie w pare sekund wygenerować PHPDOCa ze źródeł Kohany, to też jest przydatne.

[Grzesiek]

Wracając do tematu wyboru frameworka: ja mam dylemat nieco inny, zainstalowałem sobie ostatnio Symfony, które miało być frameworkiem pod mój nowy projekt i ... no nie powiem jego możliwości robią wrażenie, ale projekt nad którym pracuje będzie softem "pudełkowym", (czyli pobierasz i instalujesz na hostingu z PHP i MySQL), tymczasem z tego co do tej pory zobaczyłem - delikatnie mówiąc - Symfony średnio się do tego celu nadaje.

Po pierwsze przeglądając źródło w wygenerowanym pliku ProjectConfiguration.class.php mam linie:

[PHP] pobierz, plaintext 
<?php
require_once '/usr/share/php/symfony/autoload/sfCoreAutoload.class.php';
?>
[PHP] pobierz, plaintext 

czyli bezwzględny adres do pliku na moim localhost, nie wiem czy takich require'ów lub include'ów jest więcej, bo narazie mało co zrobiłem, ale utwierdza mnie to w moim przekonaniu

Po drugie w trac'u http://trac.symfony-project.org/wiki/SharedHostingNotSecure są specjalne patche i instrukcje jak instalować aplikacje na "shared hosting", to też mi dało do myślenia.

Na koniec, przeglądając strony zrobione przy użyciu Symfony (http://trac.symfony-project.org/wiki/ApplicationsDevelopedWithSymfony) zauważyłem że zdecydowana większość to serwisy (prawdopodobnie) na serwerach dedykowanych.

Na koniec dodam, że nie chodzi mi o to że Symfony jest złe a framework XXX jest lepszy, ale raczej o to, że Symfony nie zostało stworzone z myślą o aplikacjach które będą instalowane w setkach kopii (mam nadzieje ) na różnych hostingach, a na jednym serwerze dedykowanym i w przypadku takich aplikacji Symfony sprawdza się dobrze/świetnie/najlepiej (niepotrzebne skreślić)?

[kwiateusz]

takie require jest 1 w konfiguracji, jak zrobisz freeze to biblioteki sf zostana przekopiowane do odpowiednich katalogów i nie ma sie co tym martwić

a co do kopii to owszem sf jest bardziej pomyślane pod serwisy pojedyncze na dedykowanych maszynach, aczkolwiek działają równie dobrze na dzielonych