W tym topicu proszę umieszczać propozycje nowych tematów, na które chcielibyście porozmawiać.

Choć w temacie nie miałbym za dużo do powiedzenia z racji małej wiedzy to chętnie poczytałbym dyskusję na temat profilowania aplikacji. Może na forum znajdzie się kilka osób, które miały już z tym do czynienia i będzie chciało się podzielić swoją wiedzą.

Ja z chęcią bym podyskutował na temat modelowania warstwy kontroli dostępu w połączeniu z bazą danych itp.

Witam

Ostatnio na jednym z blogów czytałem ze klasyczny model budowania stron w ASP.NET jest zły, ponieważ Framework ASP.NET robi za duża abstrakcje dla protokołu HTTP i związanymi z nim elementami.
Post ten (oraz komentarze) dal mi dużo do myślenia i po części się z nim zgadzam. I bardzo bym chciał żebyśmy mogli tu przedyskutować temat/problem z abstrakcja. Do jakiego stopnia jest pożyteczna i kiedy zaczyna być szkodliwa ?
Temat ten jest także trochę związany z PHP bo teraz większość frameworkow tez robi abstrakcje dla wspomnianych elementów.

Pozdrawiam.

A ja chciałbym poruszyć z goła rzadko poruszany temat, bo raczej wyspecjalizowany tylko na jednym aspekcie MVC, widoków. Dokładniej sposobów obróbki danych - przekazanych do widoku - do różnych typów wynikowych.

Najlepiej będzie jak zacytuję tutaj post, który napisałem wcześniej (zanim zorientowałem się, że nie mogę tworzyć tematów na PRO ).

Ok, ale jeżeli już to temat ogólnie o MVC, ideą było to żeby nie rozdrabniać się za bardzo w tym dziale i nie robić bałaganu.

Tylko czasem to 'rozdrobnienie' stanowi temat sam w sobie.
(można umieścić temat informatyka i wszystko w nim, lub tworzenie stron internetowych obok pisania systemów operacyjnych)

[mam nadzieję, że nie robię zbytniego OT]

Założenie ogólnego tematu o MVC, nie przemawia moim zdaniem za tą ideą. Jest to bardzo obszerny temat, z założenia porusza 3 aspekty i dyskutowanie o nich w jednym wątku na pewno będzie bałaganiarskie. Udowadnia to przecież [MVC] Pytań kilka....
Wydaje mi się, że temat, który zaproponowałem jest dostatecznie, jak to mniej więcej opisał kolega powyżej, specjalistyczny, by nadawał się do PRO.

Ja bym chciał podyskutować o Zend API.
Konkretnie o umieszczaniu części lub całości logiki naszych aplikacji w formie rozszerzenia do PHP.

Każdy zauważył, że w php powstaje wiele różnych frameworków. Chętnie poczytałbym o doświadczeniach jakie z nimi macie. Może takie krótkie sprawozdania jak się sprawdził w danych zastosowaniach.
Nie chodzi mi o jałowe dyskusje, który lepszy itd., chodzi o konkretne doświadczenia w pracy, przy pisaniu konkretnych aplikacji.

Przydał by się temat pt. "Singleton vs. Registry vs. zmienne globalne" w którym ktoś może by wreszcie napisał dlaczego w/g niego zmienne globalne są bee w przeciwieństwie do tych dwóch (anty)wzorców projektowych

A może szablony jak xslt...

Ja proponuje zaawansowane metody dot. budowy aplikacji gdzie wykorzystuję się różne grupy użytkowników. np Redaktorzy, obsługa for itp, admin, super admin, gdzie można dowolnie dodawać grupy i ustalać co może a czego nie może

Ja podyskutowałbym chętnie na temat naprawdę dużych projektów i ich rozwiązań:

- duże replikacje mysql (master-slave, master-master, itp)
- farmy serwerów,
- utrzymywanie sesji przy load balancingu
- itd.

Z pewnością mamy tutaj wielu użytkowników biorących udział w takich projektach

Mnie natomiast bardzo ciekawi zaniedbywany i mało znany temat SPL. Dokumentacja praktycznie nie istnieje, więc doświadczenia innych programistów byłby mile widziane.

Co dokładnie?

• Iteratory;
• obsługa plików i folderów (po części to również iteratory);
• obsługa XML (w sumie SimpleXMLIterator);
• zabawa z tablicami (po części to również iteratory);
• wyjątki (SPL zawiera tylko definicje klas wyjątków);

czy

• obserwator

@mike
Najlepiej wszystko
Jeśli chodzi o samo działanie SPL nie mam z tym większego problemu, chociaż taki RecursiveDirectoryIterator spowodował, że się zawiesiłem przez chwilę. Najbardziej zależy mi na życiowych przykładach, porównaniu wydajności w stosunku do standardowych rozwiązań, itp.
Inną kwestią, która wychodzi poza ramy tego wątku jest to, czy klasa Iterator może być użyta do "dużej" klasy, która oprócz iterowania po jakiejś kolekcji wykonuje inne operacje. Wiem, że działa, ale czy jest to poprawne?

[PHP] pobierz, plaintext 
<?php
class Klasa implements Iterator
{
	// duzo kodu, obliczen, itp.
	public function current() {
		//...
	}
	// itd
}
?>
[PHP] pobierz, plaintext 

Czy w takim przypadku iterowanie pętlą foreach nie będzie spowodowało większego obciążenia?

@batman to może IteratorAggregate?
Ale sam niewiele używałem iteratorów, bo jakoś nie było po co.
Ale temat mógł by być ciekawy, bo można SPL używać do wielu rzeczy, a nie zawsze zdajemy sobie z tego sprawę.
Np. do przeszukania całego poddrzewa folderów i wybranie tylko plików z rozszerzeniem php to są trzy obiekty i już jadąc prostym foreach jedziemy po tych plikach... ( chyba RecursiveDirectoryIterator w konstruktorze RecursiveIteratorIterator a to w konstruktorze RecursiveRegexIterator czy jakoś tak)
A przecież jest na pewno więcej ciekawych zastosowań (zrób to samo bez iteratorów, to jest trochę kodu)

Przypomniałem sobie o jeszcze jednym zagadnieniu, które nie było poruszane na tym forum. Chodzi o XMLReader i XMLWriter. O ile o XMLWriter nie wiem zbyt wiele, to XMLReader jest bardzo dobrym sposobem iterowania po bardzo plikach XML. Te tematy również warto poruszyć.

Hehe, wyprzedziłeś tym moje wpisy na blogu, które właśnie na ten temat piszę ;-)

Akurat siedzę nad XMLReader i podobnie jak w przypadku SPL brakuje dobrej dokumentacji. Z chęcią zobaczę Twoje wpisy na blogu dot. tego zagadnienia

ja proponuję temat o ciekawych błędach w skryptach na przykład ostatnio trafił mi się taki

Fatal error: Exception thrown without a stack frame in Unknown on line 0

muszę przyznać że dostarczył mi wiele radości i śmiechu

o "ciekawych" bledach takich jak Twoj to se z kolegą przy koli możesz pogadać a nie na php Pro

Nie spamuj.

Można założyć temat o Routerach i sposobach routingu. W jaki sposób tworzyć routery na potrzeby naszych aplikacji, jakie są wydajne a jakie nie. Jakich używać a jakich nie używać.

W pełni popieram pomysł dotyczący ruterów.
Sam niedawno wziąłem się za przepisywanie swojego i wyszły mi z tego 3 klasy i całkiem sporo kodu - przynajmniej jak na router.

Prosze bardzo, temat utworzony.

A ja proponuję temat dotyczący odciązania dużych aplikacji po przez rozproszony system serwerów i ich ładną obsługę.

@SHiP: +1 wykop

Gotowe

Witam,
od dłuższego czasu chodzi mi po głowie pomysł utworzenia klasy, która byłaby swego rodzaju reprezentacją ekranu przeglądarki internetowej. Obiekt tej klasy przechowuje dane opisujące środowisko po stronie klienta (przeglądarki internetowej) takie jak jej typ (tekstowa, graficzna, inne), rozdzielczość.
Każdy inny obiekt w systemie po uprzednim wywołaniu odpowiedniej metody "dzierżawi" od tego obiektu pewną część ekranu (lub kilka), która staje się jego interfejsem.

Każdy obiekt systemu otrzymuje od obiektu obsługi ekranu informację o środowisku klienta, dzięki czemu wie jakiego interfejsu użytkownika ma użyć.

Obiekt obsługi ekranu korzysta z menadżera szablonów, który posiada informację o tym ile każdy z szablonów posiada "boxów", które mogą zostać wydzierżawione dla innych obiektów.

To tylko zarys tego o czym myślę. Mam jeszcze wiele pomysłów z tym związanych. Od razu uprzedzę, że mam odpowiednie przygotowanie aby to zrobić, jestem inżynierem informatykiem. To co napisałem powyżej po części zostało sprawdzone i działa.

Chciałbym o tym podyskutować. Czy warto dalej w to brnąć.

Chętnie przyglądnąłbym się dyskusji na temat zaproponowany przez karmera, a nawet włączył, jeśli uznam, że coś do niej wniosę .

Chciałbym zaproponować dyskusję na temat sposobów wykonania widoku.
Szczególnie zależy mi na poznaniu waszych opinii dotyczących generowania widoku przy użyciu smarty i / lub poprzez parsery XML.
Wielce nurtuje mnie i ciekawi przewaga jednej techniki nad drugą.
To czy ten temat nadaje się na Pro może być kwestią dyskusyjną. Jednak wydaje mi się że im lepszy programista tym lepszej techniki używa.
Dlatego chciałbym poznać wasze opinie.
Pozdrawiam i liczę że jest to wystarczające uzasadnienie.

Ciekawe byłoby również przedstawienie różnic wpięcia V w architekturze MVC w przodujących frameworkach (i nie tylko), a także implementacji helperów.
To o czym pisze @orglee fachowo zwie sie Rendererami.

Znalazłem na jednym z kanałów RSS informację o tym, że w październiku pojawi się beta wersja PHP 5.3. Spośród wszystkich opisanych "ficzerów", zainteresowała mnie jedna rzecz - phar. PHP-owy odpowiednik plików jar znanych z Javy. W manualu sporo o tym napisali. Może warto o tym podyskutować? Możliwości i ograniczenia takiego rozwiązania.

Phar w PHP 5.3 nie będzie nowością. Biblioteka ta obecnie funkcjonuje jako jedno z rozszerzeń PECLa. Dodatkiem jaki wniesie PHP 5.3 będzie włączenie biblioteki Phar do core'a PHP.
Nie mniej jednak zakładam wątek bo temat ciekawy: PHP Archive czyli phar

Przyszedł mi do głowy kolejny ciekawy temat - drzewa w bazie danych. Co jakiś czas przewija się taki temat przez forum i zazwyczaj podawane są dwa rozwiązania - id i parentId oraz nested sets. W ten drugi właśnie zaczynam się wgryzać i wydaje się być dobrą alternatywą dla id i parentId. Z chęcią poznam doświadczenia innych ludzi, którzy znają się bardziej na rzeczy. Czekam na wasze opinie.

W archiwum jest taki temat: Temat: drzewka_sqlowe

Nie wiem czemu nie został przeniesiony tutaj. Może warto by to zrobić teraz? Temat drzewek jest nieśmiertelny.

Doskonale powiedziane. W archiwum. Poza tym ostatni post jest sprzed ponad dwóch lat, a okres taki w świecie IT to kilka epok. Nie śledzę tematu drzewek, więc nie wiem czy nie pojawiły się jakieś nowe metody/sposoby na przedstawianie drzew lub ich optymalizację.

A ja bym się chciał zapytać o doświadczenia Tych programistów w których firmach stosuje się diagramy UML.
I jak się one mają do rzeczywistego projektu. Praktycznie każdy framework oferuje swoją drogę tworzenia oprogramowania i zastanawia mnie jak na przykład takie diagramy klas przekładają się na kod.

No to przenieś go z archiwum do otwartego.

Jeżeli chodzi o moją propozycję: Testy jednostkowe (Unit Tests). Kto używa? Kiedy użwać? Jak używać?

Witam, chciałbym rozpocząć dyskusję na temat zaawansowanej obsługi błędów w złożonych aplikacjach obiektowych.
Chodzi o koncepcję (właścwie o wzorzec projektowy) efektywnego i wygodnego debugera dla systemu składającego się z wielu hermetycznych modułów - jak większość "domowych" frameworków, z których żaden dumny autor nie chce rezygnować
Jest wiele patentów na to, ale zwykle obciążają skrypty tonami kodu.
Ogólnie, topic odpowiadałby na pytanie: "Jak najefektywniej budować wielopoziomową obsługę błędów, tak, żeby się w niej nie pogubić.".

Konkretnie interesuje mnie system, w którym każda klasa ma własny handler i potrafi w ograniczony sposób wpływać na zachowanie całego skryptu. Inne klasy, które z niej korzystają interpretują jej błędy i decydują o tym, jaki mają wpływ na ich własne zachowanie.
Jednocześnie, jak już wspomniałem, rozwiązanie tego typu, że każdą klasę dziedziczymy z jakiegoś przykładowego "errorHandlera" (*kod ponizej) nie przemawia do mnie, bo przy rozbudowanych hierarchiach zawsze trzeba zrzucać ręcznie te błędy na kolejne poziomy - przez kolejne warstwy systemu, np. od jądra, przez kontrolery, widoki, aż do szablonów. Napewno każdy, kto próbował kiedyś pisać spójną rozbudowaną bibliotekę, spotkał się z tym problemem.

[PHP] pobierz, plaintext 
<?php
// Standardowy errorHandler, którego dzidziczą wszystkie klasy w systemie.
// Oczywiście, to tylko najprostszy przykład.
 
class errorHandler {
    private $errors = array();
    
    function isError() {
        return !empty($this->errors);
    }
    
    function lastError() {
        return array_pop($this->errors);
    }
    
    function setError($message) {
        $this->errors[] = $message;
    }
    
    funciton clearErors() {
        $this->errors = array();
    }
}
?>
[PHP] pobierz, plaintext 

Oczywiście proponuję ogólną dyskuskę na ten temat - o szczegółach napisałem tutaj tylko, żeby było wiadomo, o co mi właściwie chodzi

Witam,

Ostatnio coraz to częściej zdarza mi się mieć wyrzuty sumienia zwiazane z tym czy aby napewno nie zagalopowałem się z projektem systemu, czy nie przesadziłem z modularnością, elastycznością, konfiguralnością, odzielaniem coraz to różniejszych warstw (dla przykładu kiedyś myśląc o projekcie zaczynałem z 3 warstwami, teraz żadko mi się zdarza - częściej "na dzień dobry" zaczynam od 5 warstw ).

Bardzo mi się spodobały artykuły Michała Gołębiowskiego oraz Simon-a Guest-a w tym temacie.


Więc proponuję, utworzyć nową dyskusję na temat tego kiedy zanika ta cieniutka linia pomiędzy dobrym, modularny i elastycznym projektem a "over engineering".

Pozdrawiam.

Przyłączam się do obu powyższych próśb o utworzenie tematów. W archiwum jest co prawda temat o debugowaniu skryptów, ale ma on 3 lata. Jak dla metodologi odpluskwiania to całe wieki. Chciałbym się dowiedzieć jak powinno się postępować przy wystąpieniu błędu, którego nie da się od razu zlokalizować. Jaka w takich przypadkach powinna być procedura postępowania. Z góry dziękuję.

Witam,
prosiłbym o utworzenie tematu o "Tworzeniu API do wykorzystania przez zewnetrzne serwisy".
Najbardziej chodzi o dyskusje o tym jak powinna wygladac komunikacja (jaki protokół wykorzystać). W jaki sposob obudowywac serwis dodatkowym api. Czy tworzyc calkowicie odrebne pliki z funkcjami, czy tez moze jak wplesc razem.

Także przyłączam się do tematu na temat debugowania skryptów php.

Jak już się przyłączamy to ja oddaje głos na API.
Będę robił właśnie coś podobnego i fajnie byłoby nie popełniać kardynalnych błędów.
Debugowanie też popieram ;-)

Jak piszemy aplikację php? Czy używamy jakiegoś frameworka? Jakiego? Co się dla nas liczy przy pisaniu aplikacji? Szybkość ich tworzenia, czy szybkość działania samej aplikacji?

Również jestem za API. Jak PRO to PRO, a nie jakieś pierdy, które co drugi programista jest w stanie wykonać.

Ja jestem za tematem Routing - Routery, wg mnie dość ciekawy.

Ehh...
Temat: Routery i sposoby routingu