Wypowiedzi
-
Tomasz Madeyski:
tak, tylko wlasnie problem jest z tym czystym sql - jak powinno wygladac wywolanie funkcji zwracajacej wartosc przy zalozeniach:
- nie mozna jej wywolac w formie select funkcja from dual
- parametry do funkcji musza byc przekazane przez "bind" (ze wzgledow bezpieczenstwa)
Jeśli chcesz mieć dostęp do api PDO z bindowaniem parametrów to spróbuj
$pdo = Doctrine_Manager::getInstance()->getCurrentConnection()->getDbh();
Zwraca Ci ono obiekt PDO, więc masz wszystko czego potrzebujesz.
i potem przykładowe bindowanie np. dla selecta, ale dla procedur i funkcji jest podobnie
$sth = $pdo->prepare('SELECT name, colour, calories
FROM fruit
WHERE calories < :calories AND colour = :colour');
$sth->bindParam(':calories', $calories, PDO::PARAM_INT);
$sth->bindParam(':colour', $colour, PDO::PARAM_STR, 12);
$sth->execute();
$rs = $stmt->fetchAll();
-
Nie kwestionuję tego, że HYDRATE_NONE jest szybsze niż HYDRATE_ARRAY. Dyskutowałbym nad tym, że HYDRATE_ARRAY jest dużo szybsze od budowania obiektów.
IMHO jest to istotne tylko w krytycznych punktach naszych aplikacji.
Masz absolutną rację, z kolei ja mówiłem to w kontekście zupełnie innego problemu bo
$this->q = Doctrine_Query::create()
->select('a.content, a.id_article, a.priority')
->from('Article a')
->innerJoin('a.SectionArticle sa')
->where('sa.section_id = ?', $this->id_section)
->orderBy('a.priority ASC')
->limit(1)
->execute()
->toArray();
w zapytaniu które przedstawiła koleżanka są po sobie execute a potem toArray() czyli najpierw budowana jest kolekcja obiektów Doctrine_Collection a potem tablica asocjacyjne i głownie na tym polegała moja uwaga, a kwestie różnic widać przy fetchach rzędu tysiąc i więcej.
Pozdrawiam
Ps. niedawno utworzyłem konto na symfonyexperts i widzę, że ładnie tam kasujesz :P
-
Dobrze by było jakbyś napisała konkretny kod błędu validatora czy coś w tym stylu, stawiam, że problem jest z tym, że symfony ma problem z przetwarzaniem zagnieżdżonych formularzy jeśli wykonują dodatkowe akcję. W tym wypadku tak jest ponieważ hierarchia wywołań wygląda tak:
$form->save()
| $form->doSave() // aktualizacja i zapis
| $form->updateObject()
| $form->processValues() // ustalanie wartosci
| $form->processUploadedFile($field);
| $form->getValue($field)
| $form->saveFile($field)
| $form->object->fromArray(...);
| $form->object->save()
Oznacza to, że formularz potomny nigdy nie zwróci ci "czystych" wartości poprzez getValue() których wymaga funkcja processUploadedFile().
fix który ma na celu wypełnienie formularza zwalidowanymi wartościami. Umieść go sobie w klasie z której dziedziczą twoje formsy.
public function bind(array $taintedValues = null, array $taintedFiles = null)
{
$ret = parent::bind($taintedValues, $taintedFiles);
foreach ($this->embeddedForms as $name => $form) {
$this->embeddedForms[$name]->isBound = true;
$this->embeddedForms[$name]->values = $this->values[$name];
}
return $ret;
}
Mi to rozwiązanie kiedyś pomogło, nie mniej jednak wejdź na stronę:
http://stereointeractive.com/blog/2008/12/23/symfony-1...
gdzie gość opisuje podobny problem.
-
Jakub Zalas:
Łukasz Adamczewski:
Nie polecam takiego rozwiązania, ponieważ domyślnie działa to tak, execute powoduje, że wszystkie dane zostaną pobrane jako obiekty, oraz zostanie zwrócona kolekcja Doctrine_Collection ze zagregowanymi obiektami - jest to rozwiązanie bardzo czasochłonne. Jeśli chcesz odnosić się bezpośrednio w notacji tablicowej (wydajne rozwiązanie), polecam poniższy kod:
$this->q = Doctrine_Query::create()
->select('a.content, a.id_article, a.priority')
->from('Article a')
->innerJoin('a.SectionArticle sa')
->where('sa.section_id = ?', $this->id_section)
->orderBy('a.priority ASC')
->limit(1)
->execute(array(), Doctrine::HYDRATE_ARRAY); // albo Doctrine::HYDRATE_NONE - szybsze
W ten sposób nie jest tworzona kolekcja obiektów tylko tablica asocjacyjna, sprawdź czas działania, gwarantuje, że będzie kilkanaście razy szybszy.
Robiłeś testy? Ostatnio, kiedy to sprawdzałem Doctrine oszczędzał tylko nieco pamięci. Nadal "budował" te tablice i nie było to najwydajnieszjsze. Najszybciej jest z HYDRATE_SCALAR (ale nie za wygodnie).
Oczywiście, nie zawsze potrzebujemy, żeby było "najszybciej". Czasem wygoda jest ważniejsza niż wydajność.
Testów nie robiłem, ale powołuje się na
http://www.doctrine-project.org/documentation/manual/1...
gdzie piszą coś w stylu
There are two important differences between HYDRATE_ARRAY and HYDRATE_NONE
which you should consider before choosing which to use. HYDRATE_NONE is the fastest but the result is an array with numeric keys and so results would be > referenced as $result[0][0] instead of $result[0]['my_field'] with
HYDRATE_ARRAY. Best practice would to use HYDRATE_NONE when retrieving large record sets or when doing many similar queries. Otherwise, HYDRATE_ARRAY is more comfortable and should be preferred.
Ale oczywiście dla wyników countów i zwracania wartości pojedynczych kolumn HYDRATE_SCALAR jest najszybszeŁukasz Adamczewski edytował(a) ten post dnia 02.05.11 o godzinie 23:31
-
Przemysław R.:
Witam
Buduję sobie framework - tak dla treningu - i zastanawiam się w którym miejscu dodać sprawdzenie dostępu do jakiegoś kontrolera. W kontrolerze, routerze a może gdzieś indziej?
Prosił bym bym o jakieś pomysły i koncepcje
Moim zdaniem całkiem przyzwoicie sprawdza się w tym przypadku wzorzec Chain of Responsibility.
W ten sposób zaczynasz na liście metod do przetworzenia, zaczynasz od ACL jeśli przechodzi możesz zrobić jakiś proces zczytywania z cache'a, potem obsługa żądania i rendering strony.
Idea, którą przedstawiłem występuje np. w symfony i moim zdaniem to całkiem ciekawe rozwiązanie.
-
Maciej Wilgucki:
Wracając do tematu. Ostatnio miałem podobny problem. Okazało się, że Opera i IE miały głęboko w poważaniu wszelkiej maści ajaxowe nagłówki i ich po prostu nie widziały. Tak więc ostrożnie z tym wykrywaniem requestów ajaxowych.
Widzieć widzą, ale jeśli nie wysyłasz od razu jakiegoś unikalnego parametry dołączonego url'a to będą z wysokim prawdopodobieństwem przy pierwszej okazji cache'ować wynik.
-
Katarzyna Idczak:
Rozwiązanie, jakby kiedyś komuś miało się przydać, wygląda tak:
$this->q = Doctrine_Query::create()
->select('a.content, a.id_article, a.priority')
->from('Article a')
->innerJoin('a.SectionArticle sa')
->where('sa.section_id = ?', $this->id_section)
->orderBy('a.priority ASC')
->limit(1)
->execute()
->toArray();
Pozdrawiam.
Nie polecam takiego rozwiązania, ponieważ domyślnie działa to tak, execute powoduje, że wszystkie dane zostaną pobrane jako obiekty, oraz zostanie zwrócona kolekcja Doctrine_Collection ze zagregowanymi obiektami - jest to rozwiązanie bardzo czasochłonne. Jeśli chcesz odnosić się bezpośrednio w notacji tablicowej (wydajne rozwiązanie), polecam poniższy kod:
$this->q = Doctrine_Query::create()
->select('a.content, a.id_article, a.priority')
->from('Article a')
->innerJoin('a.SectionArticle sa')
->where('sa.section_id = ?', $this->id_section)
->orderBy('a.priority ASC')
->limit(1)
->execute(array(), Doctrine::HYDRATE_ARRAY); // albo Doctrine::HYDRATE_NONE - szybsze
W ten sposób nie jest tworzona kolekcja obiektów tylko tablica asocjacyjna, sprawdź czas działania, gwarantuje, że będzie kilkanaście razy szybszy.
-
Adam W.:
Łukasz Adamczewski:
Zobacz logi w log/srodowisko_dev.log na środowisku develperskim, na 100% zapytanie musi być poprawne, ale może nazwa relacji się inaczej nazywa albo w kolumnie literówka
jeżeli jest błąd w nazwie kolumny, czy zła nazwa relacji doctrine zwraca błąd, który powinien wyświetlić się.
Jeśli error_reporting albo error_display i do tego w symfony jest to wszystko wyłączone to wszystkie błędy zostaną stłumione, dlatego poleganie na logach php i symfony jest zawsze niezawodne.
Ps. ponieważ pisałaś jeszcze na grupie doctrine odsyłam też tam
http://www.goldenline.pl/forum/2381732/zapytanie-w-doc...Łukasz Adamczewski edytował(a) ten post dnia 01.05.11 o godzinie 15:21
-
-
Przy tego typu rozwiązaniach trzeba uważać tylko na jeden szkopuł, ponieważ ta flaga jest wysyłana tylko wtedy kiedy akcja nie jest cacheowana, a jak cacheujesz wyniki działania określonych widoków to mogą czasem wyniknąć jaja. Inna sprawa to fakt cache'a IE < 8 który ma głupi zwyczaj cacheować xmlhttprequesty, więc np w jquery ważne jest by używać:
Łukasz Adamczewski edytował(a) ten post dnia 01.05.11 o godzinie 11:54
$.ajax({
cache: false,
// inne parametry
});
-
-
Może baza działa tylko lokalnie natomiast jest zablokowana do dostępu zewnętrznego.
Z drugiej strony w manualu od PHP masz
// Server in the this format: <computer>\<instance name> or
// <server>,<port> when using a non default port number
$server = 'KALLESPC\SQLEXPRESS';
// Connect to MSSQL
$link = mssql_connect($server, 'sa', 'phpfi');
if (!$link) {
die('Something went wrong while connecting to MSSQL');
}
?>
więc wydaje mi się, że podajesz nazwę instancji, ale nie nazwę komputera na którym stoi.
-
Na początku nie doceniałem tego narzędzia i traktowałem wyłącznie jako pewien bajer, ale wraz z zapoznaniem się ze specyfikacją CollectionRoutes oraz możliwościami rozszerzania i tworzenia nowych motywów, generatory stały się naprawde potężnym narzędziem, zwłaszcza kiedy generatory udostępniają mnóstwo ciekawych eventów do indywidualnego obsłużenia.
-
Zależy do czego chcesz używać danego frameworka.
Ja od frameworków oczekuje dobrego wsparcia ORM + możliwości automatyzacji generowania modelu bazowego.
Dużej społeczności + systemowi łatwych do dodania pluginów
Możliwości lokalizacji tworzonego oprogramowania na różne języki.
Optymalizacji działania i wpieraniu rozwiązań takich jak APC czy MemCache oraz buforowanie czasowe stron i operacji w widoku.
Łatwego w użyciu systemu routingu.
Ułatwieniu pracy przy użyciu scaffoldingu.
Możliwości zastosowania natywnej obsługi zdarzeń.
Bezpieczeństwa dzięki wbudowanym zabezpieczeniom XSS, XSRF i SQL Injection
Dobrej obsługi widoków, szablonów głównych i generalnie możliwości rozczłonkowania pewnych elementów które powtarzają się na różnych podstronach.
Dobrej dokumentacji oraz dobrze opisanego API.
Jeśli myślicie, że to co napisałem to idylla to zapraszam do frameworka symfony. Jeśli wasz framework ma to wszystko to z chęcią się zapoznam.
-
NOTE: This directory requires write access by PHP. That is,
PHP must be able to create files in this directory.
Able to create directories is nice, but not necessary.
*/
//$IMConfig['base_dir'] = $_SERVER['DOCUMENT_ROOT'] . 'uploads/Image';
////$IMConfig['base_dir'] = $_SERVER['DOCUMENT_ROOT'] . '/xxx/uploads/Image';
$IMConfig['base_dir'] = $_SERVER['DOCUMENT_ROOT'] . '/xxx/uploads/Image';
Jak sama nazwa wskazuje tutaj następuje deklaracja miejsca gdzie mają siedzieć uploadowane pliki. W aplikacjach Symfony DOCUMENT_ROOT wskazuje na folder web, więc wydaje mi się, że wystarczy użyć:
Łukasz Adamczewski edytował(a) ten post dnia 14.04.11 o godzinie 19:43
$_SERVER['DOCUMENT_ROOT'] . '/uploads/';
-
-
Serializacja obiektów w bazie to chyba niezbyt mądry pomysł. Nie lepiej zastosować jakieś mapowanie obiektowo relacyjne i przechowywać dany obiekt w stricte relacyjny sposób.
Z tego co widać to nie jest problem kodowania, ponieważ ma problem przy ś w "oszczędność", natomiast nie ma przy "głośna", więc to na pewno nie to. Z całą pewnością musisz przejrzeć metodę serializującą.
Jako alternatywę zrób serializację przy użyciu json_encode / json_decode. W ten sposób masz bardziej czytelną formę obiektu w bazie, z drugiej strony zestawienie tych metod jest szybsze niż serializacja / deserializacja w PHP
-
Witam, od początku zaznaczam, że jestem kompletnie "zielony" w tematyce springa i dopiero zaczynam z nim pracę (4 dzień). Chciałbym się dowiedzieć czy możliwości ResourceBundleMessageSource są dostępne z poziomu pliku jsp w definicji welcome-file-list. Pytam ponieważ tag
<spring:message code="..">
działa wszędzie tam gdzie mam widok, który jest zwracany przez konkretne kontrolery, natomiast dla index.jsp, który jest domyślnym widokiem dla aplikacji funkcjonalność messagesów nie działa. Jest to do tego stopnia dziwne, że korzystając z
<spring:message code="register_link" message="?register_link"></spring>
na stronie index.jsp, która includuje plik menu.jsp, którego fragmentu podałem powyżej, pokazuje oczywiście ?register_link, natomiast dla innych widoków poprawną wartośc z message.properties Z góry dziękuję za jakąkolwiek pomoc.Łukasz Adamczewski edytował(a) ten post dnia 09.04.11 o godzinie 19:12
-
Ja wykorzystuje event dispatcher do usuwania cache dla konkretnych modułów lub modeli danych.
Użyłem też dispatchera do regulowania kwestii co pokazywać w formularzach, a co nie, np. w ten sposób wymusiłem, że zmiane ownera danej encji można wykonać tylko jako osoba z określonymi uprawnieniami. (event inicjalizujący form'a).
Generalnie obsługa zdarzeń najlepiej sprawdza się jako sposób na centralizację pewnych zachowań i obługę w konkretnej klasie.
Wysłanie maila po jakimś zdarzeniu lub akcji to kolejny przykład operacji, które niejako działają w tle i fajnie jest dodać kod obsługi w jednym miejscu.
Twórcy symfony pisali coś o eventach w kontekście np. aktualizacji stanu konta usera po jakiejs akcji typu kup itd.
Innym podejściem jest stosowanie event dispatcherów jako pewnego rodzaju filter chainów, czyli dany obiekt ma kilka elementów preprocessingu, które są implementowane przez różne klasy nasłuchujące.
Odnośnie tego, przychodzi mi tylko do głowy przetwarzanie zdjęcia na zasadzie wysyłasz event typu utworzono obiekt graficzny, ktory w kolejnych krokach filter dodaje zaokrąglone rogi, znak wodny, oraz miniatury w różnych wielkościach, zwracając ostatecznie obiekt do zapisu.
Nie da się ukryć, że stosowanie eventów musi być zamierzone i trzeba pamiętać co gdzie jest obsługiwane bo debugowanie może być koszmarem.
-
Jakub Zalas:
Czy migrować? Jeśli projekt żyje - jak najbardziej! Jeśli nie będzie rozwijany - zastanowiłbym się, bo może nie warto. W każdym razie spróbuj uruchomić migrację. Jakub Zalas edytował(a) ten post dnia 07.04.11 o godzinie 20:43
Gorzej jak żyje i przestanie za sprawą upgrade'u :P
W wersji 1.3 oczywiście pliki ustawień przechodzą zmiany zwłaszcza settings.yml. Na pewno trzeba uważać na migrację pluginów - m.in sfGuardPlugin będzie wymagał upgrade'u, no i generalnie wszystkie klasy tasków, które były pisane będą musiały zostać zmienione dla 1.3.
Trochę też pobawisz się z formularzami bo też trochę klas widgetów zostało wykluczonych.
- 1
- 2
- 3
- 4
- 5
- Następna »
