Forum PHP.pl

Nie lepiej, bo obsługa wartości bez znaku jest w wielu platformach mocno utrudniona - z PHP na czele - a niczego Ci nie daje w tym kontekście. Nie mówiąc już o dużych problemach w mieszaniu arytmetyki typów z i bez znaków.To będzie wina złego projektu aplikacji czy bazy danych, nie samej platformy/technologi. Nie przy takich wartościach.
To że jakaś wartość jest dominująca nie powinno być samo w sobie przesłanką do korzystania z wartości domyślnych. Przy czym jest to raczej mało istotna kwestia.1. Symfony nie ma tutaj nic do rzeczy - to specyfika języka.
2. Jeżeli nulle nie mają sensu dla Twojego modelu danych - bardzo częsta sytuacja i w sumie jeszcze częściej mocno pożądana - nie umożliwiaj w ogóle ich podania. Od tego są konstruktory by wymusić podanie odpowiednich danych. Jeżeli zaś danych jest za dużo na konstruktor masz do dyspozycji całą paletę sprawdzonych wzorców budowniczych pozwalających konstruować złożone obiekty.
3. Jeżeli jakieś wartości trzeba ustawić to... to je ustaw.

1. Nie każda warstwa abstrakcji będzie powodowała spowolnienie, jeżeli np. sama w sobie potrafi coś optymalizować, co normalnie by optymalizowane nie było - np. Second-Level Cache z Doctrine'a.
2. Ilość danych w bazie nie ma dla samego Doctrine'a specjalnego znaczenia.
3. Znaczenie będzie miała natomiast liczba wyciąganych przez dane zapytanie danych. Przetworzenie przykładowo 100 000 rekordów z bazy danych przy pomocy "czystego PHP-a" może być znacząco szybsze niż zrobienie tego z wykorzystaniem Doctrine'a ze względu na powolność PHP-a w tworzeniu obiektów jako takich.
4. Musisz sprawdzać jakie zapytania SQL finalnie generuje Doctrine. A że pracując z ORM-em często łatwo się zapomnieć w tym aspekcie stąd opinia n/t "powolnych ORM-ów".

Na takie pytanie można odpowiedzieć jedynie mając kontekst konkretnego przypadku.
I generalnie rzecz biorąc ta książka bardzo dobrze mówi. Co zatem w przypadku, gdy w kontruktorze potrzebowałbym 23 argumentów? Najprawdopodobniej mamy do czynienia ze źle zaprojektowanym obiektem, który próbuje zajmować się zbyt dużą liczbą rzeczy na raz.
Kontrolery to dokładnie takie same klasy jak wszystkie inne. Nie powinny spinać wszystkiego, bo co jest do wszystkiego to jest do niczego. ;-) Z jakiegoś powodu da się w sieci znaleźć "odczucia", że kontrolery to jakieś specjalne klasy - nie, nie są w żaden sposób wyjątkowe.
Wręcz dokładnie odwrotnie. :-) To własnie klasy/metody z części "logiki biznesowej" potrzebują wykonać całą ciężką pracę w programie, więc to w nich znajdziemy sporo zależności. Inną kwestią jest to, że nadal trzeba trzymać się zasady - im mniej zależności tym lepiej.

W skrócie: musiałbyś podać konkrety przypadek do omówienia (code review) nawet w jakimś pseudokodzie, bo tak to będziemy prowadzić akademicki wywdów.

1. JavaScriptu nie Javy.
2. Od razu polecam zaznajomić się z biblioteką RxJS - jest idealna do tego typu zadań.
3. Powyższy kod jest raczej słabej jakości, nie jest to najlepszy przykład do wzorowania się.
4. Jestem całkiem pewien, że część z tego kodu rozumiesz. Napisz dokładnie co jest niejasne.

Tutaj niestety wychodzi porównanie wydajności pomiędzy kodem napisanym w C + PHP (wbudowany moduł od obsługi XML w C wykorzystywany przez API w PHP) konta czyste PHP. Co tu dużo mówić, PHP jest wolny. Co możesz zrobić?
1. Upewnij się, że korzystasz z PHP 7.x nie 5.x - jest zauważalnie szybszy, ale na pewno nie zniweluje Ci to różnicy.
2. Poszukaj jakiegoś prasera, który został napisany jako moduł w C dla PHP. Wtedy powinieneś uzyskać czasy takie jak w przypadku XML-a. Przy czym nie mam pojęcia czy takowy istnieje.
3. To już jest obejście, nie rozwiązanie problemu:
3.a. Przy pomocy zewnętrznego, wydajnego softu konwertuj sobie JSON do XML przed przetworzeniem.
3.b. W ogóle skorzystaj z innej platformy.

1. Debugger PHP i po kolei przejść kod wykonywany w ramach EntityManager::flush()?
2. Logi zapytań wysyłanych do bazy danych?

1. By SomeUnique2 mogło działać dla klasy musi mieć napisaną metodę getTargets(), która powinna zwrócić self::CLASS_CONSTRAINT.
2. Oż Ty leniuszku... http://api.symfony.com/3.1/Symfony/Compone...tInterface.html :-P (np. getRoot()).

Miejsce przechowywania tego typu zasobów może być przeróżne (lokalny system plików, FTP, usługa składowania plików w AWS-ie/Google-u/Azure-ze/innych, baza danych, itp. itd.) Osobiście mogę polecić KnpGaufretteBundle (integracja dla Symfony z KnpLabs/Gaufrette), które wprowadza całkiem fajną abstrakcję nad faktycznym miejscem składowania zasobów.

1. Symfony nie ma absolutnie nic do powiedzenia w kwestii przechowywania plików.
2. Jeżeli jest to pojedyczny plik po prostu wrzuć go sobie do jakiegoś katalogu albo wręcz bezpośrednio w folderze publicznym (web, public, public_html czy jakkolwiek się on nazwa).

W przypadku PHP nie są one może niezbędne jak w niektórych platformach, ale nadal mają kilka zalet.

1. Zamiast wykorzystywać mocki/stuby w testach możesz skorzystać z "głupich implementacji", a w przypadku jakiś usług operujących na zew. zasobach z implementacji operujących w pamięci. Czy to samo da się osiągnąć przy pomocy wspomniach mocków/stubów? Generalnie tak, ale z wygodą często nie ma to nic wspólnego.
2. Rozsądnie zaplanowane interfejsy - czyli takie z małą liczbą metod - pozwalają na zmniejszenie liczby zależnośći. Często można mieć klasę implementującą kilka interfejsów. W momencie gdy testujemy coś wymagającego tylko jednego interfejsu tej klasy zmniejsza się liczba metod które wymagają mocków/stabów.
3. Poleganie na tym, że "dla reszty metod zwracany jest null" jest bardzo niebezpieczne na dłuższą metę i sprawia, że Twoje testy muszą mieć jakąś świadomść wewnętrznej implementacji testowanej klasy - a to lekko negatywnie wpływa na stabilność samych testów.

Tak nie do końca identyczne: https://www.diffchecker.com/3Tgvzb4D

Podany fragment kodu z tego bloga to idealny przykład jak kompletnie spartaczyć sobie obsługę i debuggowanie błędów. Tego typu kod to dosłownie same problemy.

Przede wszystkim jeżeli nie masz żadnej możliwości zareagowania na wyjątek, ani możliwości zignorowania go pod żadnym pozorem nie łap go - wyrządzasz sobie w ten sposób jedynie krzywdę. Zauważ, że w tym kodzie:
1. Tracimy informację o miejscu wystąpienia błędu. W linii #8 nie doszło tak na prawdę do żadnego błędu (miało to miejsce w czymś co tutaj kryje się pod komentarzem z linii #4). Tracimy BackTrace'a.
2. Tracimy informację o tym co spowodowało wyjątek - dostaniemy tylko nic nie mówiący ControllerException z komunikatem w stylu "There was an error: Connection TimedOut". Jeżeli jeszcze zapisałby oryginalny wyjątek czy w praktyce zapewne ich całą hierarchię...
3. W kodzie kontrolera, który generalnie powinien kompletnie nie interesować się źródłem danych (baza danych, PDO) musimy tworzyć tego typu zależność.

I jeszcze odnośnie Twoich wcześniejszych notatek dot. łapania i ponownego rzucania wyjątków.
1. Tak, możesz wyłapać wyjątek zew. biblioteki i opakować go we własny, tylko pamiętaj by przekazać go w parametrze, jako innerException.
2. Jeśli nie jesteś wstanie nic z nim zrobić to nawet nie kombinuj z łapaniem go i ponownym wyrzucaniem bez żadnej pobocznej akcji jak chociażby zalogowanie go - sam to zrobi.

PS. Nie mogę pozwolić sobie teraz na lekturę tego wpisu, ale powyższy fragment spowodował u mnie zapalenie się takiej ostrzegawczej lampki w głowie. ;-)

1. Element BUTTON jak najbardziej może być wykorzystywany do wysyłania formularza. Pasowałoby jedynie dodać mu atrybut type=submit.
2. Obecnie można praktycznie zapomnieć o czymś takim jak "wyłączony JS" w normalnego użytkownika.

Kod HTML to zwykły tekst i nie ma on żadnego znaczenia ani dla bazy danych, ani dla PHP-a. Zapisuj go normalnie, tj. w surowej niezmienione formie. Jeżeli te dane chcesz później wyświetlić w na stronie w HTML-u musisz zadbać o to by nie został on zinterpretowany jako HTML, czyli wykorzystać htmlspecialchars.

Zapewne chodzi tutaj o zbiór kilku technik/narzędzi wykorzystywanych w ramach Symfony, które pozwalają na dodawanie (bądź usuwanie) pewnych zachowań. Trochę ciężko bez szerszego kontekstu to wyciągnąć. Czym będą te narzędzia? Przede wszystkim:
1. Zdarzenia, które rzuca sam FW, np. od obsługi żądania HTTP czy formularzy.
2. Konfiguracja kontenera wraz z poprawnie utworzonymi usługami (IoC / wykorzystanie interfejsów), pozwala bardzo często na podmianę tylko drobnego kawałka logiki, która nas interesuje.
3. Tagi w kontenerze zależności.

W skrócie: tak - test musi skądś wiedzieć jaka wartość jest uznawana za odpowiednią/wzorcową.

W takim przypadku nie ma takiej potrzeby, ale dla czytelności lepiej jest albo wykonywać importować przestrzeń albo wykorzystywać "odwołanie globalne" z ukośnikiem na początku.

Dodaj modyfikator u do wyrażenia: http://ideone.com/XZ7KVj

Możesz spróbować wyrzucić odwołania do nieszczęsnej klasy statycznej do pośredniczącego obiektu.

[PHP] pobierz, plaintext 
class Config {
  public static get(...);
  public static set(...);
}
 
interface ConfigProviderInterface {
  public get();
  public set();
}
 
// implementacja wykorzystywana w normalnym kodzie
class StaticConfigProvider implements ConfigProviderInterface {
    public get() {
        return Config::get(...);
    }
 
    public set() {
        Config::set(...);
    }
}
 
// implementacja wykorzystywana w testach
class ArrayConfigProvider implements ConfigProviderInterface {
    private $config;
 
    public get() {
        return $this->config[...];
    }
 
    public set() {
        $this->config[...] = ...;
    }
}
 
class MyClass {
  private $config;
 
  public __construct(ConfigProviderInterface $config) {
    $this->config = $config;
  }
 
  public doSth() {
    return 'abc' . $this->config->get(..);
  }
}
 
// ---- TESY:
 
$config = new ArrayConfigProvider([....]);
$class = new MyClass($class);
 
$this->assertEquals('abc123', $class->doSth());
[PHP] pobierz, plaintext 

array_count_values

https://developer.mozilla.org/en-US/docs/We...bjects/Math/pow

[JAVASCRIPT] pobierz, plaintext 
Math.pow(-7, 0.5); // NaN (negative numbers don't have a real square root)
// due to "even" and "odd" roots laying close to each other, 
// and limits in the floating number precision, 
// negative bases with fractional exponents always return NaN
Math.pow(-7, 1/3); // NaN
[JAVASCRIPT] pobierz, plaintext 

Na dobrą sprawę kod Symfony z Twoim kodem nie ma styczności, więc bez znaczenia jaki styl sobie obierzesz. Ten forsowany przez Symfony jest całkiem sensowny, jednak również ma swoje ułomności - które wymieniłeś.

1. Przecinek po ostatnim elemencie był zawsze dla mnie kompletnie niezrozumiały. Nie daje on w praktyce absolutnie niczego, nie jest też jakiś "ułatwieniem" dla automatów modyfikujących kod. Innymi słowy jest kompletnie zbędny.
2. Yoda Conditions... zamiast z takiego potworka korzystaj zawsze (może poza wyjątkowymi sytuacjami) z operatora identyczności (===) zamiast równości (==). Zmienne i tak zawsze powinny mieć jeden znany typ. === już nie da się pomylić z =, zresztą tego typu wpadka i tak momentalnie Ci się objawia niedziałającym systemem/testami.

Zapewne dla właściwości @Id masz ustawione automatyczne generowanie wartości (@GeneratedValue(AUTO)). Wtedy Doctrine zignoruje ręcznie ustawioną wartość przez setId(x).
Jeżeli decydujesz się na ręczne bądź półautomatyczne (np. przy pomocy sekwencji) nadawanie ID-ków, to taką metodę setId() jak najbardziej możesz czy wręcz musisz mieć. Generalnie nawet jeżeli ID-ki generowane są wyłącznie przez bazę danych metoda setId() wiele nie wadzi, a przy pisaniu testów może się przydać.
Liczba linii kodu jest bez znaczenia. Chodzi po prostu o to, że kontroler to nie miejsce dla ORM-a, który raczej powinien być użyty dopiero gdzieś głęboko w warstwie przetwarzania danych, czy właściwie dostępu do danych. Ale nie zawsze potrzebujemy takiej separacji kodu, na różne warstwy stąd Symfony udostępnia "łatwy" dostęp do Doctrine'a wewnątrz kontrolerów dziedziczących po Symfony\Bundle\FrameworkBundle\Controller\Controller.

https://github.com/twbs/bootstrap/blob/mast...ables.less#L325 - tutaj masz zdefiniowaną zmienną z liczbą kolumn - musiałbyś ją zmienić na 16 i skompilować sobie Bootstrapa.

Edit: Czyli dokładnie to co @Pyton_000 podesłał.

Przy liczbie raptem kilkudziesięciu tysięcy nie powinieneś mieć żadnych problemów z wydajnością. Powinieneś skupić się na poprawnej strukturze bazy.
1. Artykuły, kategorie i autorzy to osobne obiekty więc powinny być w osobnych tabelach.
2. Kategorie i podkategorie to jak domyślam się dokładnie ten sam typ obiektu jedynie w strukturze drzewiastej - powinno być w jednej tabeli. Co do samego drzewka w sieci jest od groma informacji na ten temat.
3. Artykuły i kategorie są powiązane klasyczną relacją wiele-do-wielu więc będziemy mieli dodatkową tabelę wyłącznie na potrzeby tej relacji, tak jak podałeś.
4. Jeżeli będziesz chciał wyszukiwać artykuły nie "w jednej z n kategorii" tylko "będące we wszystkich n kategoriach" od razu zapisz sobie w zakładkach mój post z innego wątku z dzisiaj: http://forum.php.pl/index.php?s=&showt...t&p=1186255