Witam w moim systemie(fw) obsluguje biblioteki jak i helpery(jak narazie nie mam zadnego).

Chce sie dowiedziec jaka u was jest roznica pomiedzy biblioteka a helperem.

Ogolnie rzecz biorac nie znalazlem zadnej interesujacej mnie odpowiedzi w google jesli chodzi o roznice pomiedzy biblioteka a helperem jednak mam moje zdanie, widzac tez jak dziala to w kohanie lub fw przedstawionych na forum(rapide,mohebo,vframe) do ktorych niestety nie mam kodu tylko watek z forum.

Ja to widze tak:

-Library: czyli klasa ktora pelni dana role potrzebna mniej lub wiecej samemu systemowi by dzialal, lub jakies stale rozszerzenia systemu tak ogolnie mowiac, mam nadzieje ze rozumiecie co chce przez to powiedziec.

-Helper: klasa ze zbiorem krotkich metod ktora pomoga bibliotece lub danemu komponencie/pluginu, niezalezna od samego systemu.

Teraz tak widzialem rozne implementacje helperow jako klasy tylko z metodami statycznymi lub zwykle klasy jak lib z mniejsza funkcjonalnoscia.

Ktora metoda jest najbardziej odpowiednia?

I czy helper powinien byc jakby to powiedziec "czescia" widoku tzn jego wywolanie powinno znajdowac sie w widoku lub jako klasa w kontrolerze komponentu/pluginu?

Patrzac np na kohana(http://docs.kohanaphp.com/helpers/upload) widac ze helper dziala razem z kodem biblioteki w kontrolerze, jednak w rapide(http://forum.php.pl/index.php?showtopic=53356&view=findpost&p=291964) wszystko jest w widoku.

Nie wiem czy obydwie implementacje sa prawidlowe lub jest to widzimisie kodera i jego wygody?

Pytam bo chcialbym zrobic to jak najlepiej i jak najbardziej dzielic wszystko na biblioteke/helper

Biblioteka - Zbiór ścisłe ze sobą współpracujących klas/obiektów. Mogą posiadać skomplikowane API.
Helpery - funkcje lub obiekty zawierające w sobie - mniej lub bardziej skomplikowaną - logikę udostępnioną w prostym API. Zazwyczaj korzystają z bardziej rozbudowanych bibliotek. Mogą przybrać formę zwykłego proxy.

Osobiście helpery widzą mi się jako obiekty (hermetyzacja i wszelkie udogodnienia OOP).

W Kohanie również są helpery, które wykorzystuje się w widokach (np. Form, HTML, Text...). Część z nich faktycznie używa się w kontrolerach (np. Email), a część tu i tu (np. URL). Mi osobiście taka dowolność pasuje, a kwestia miejsca użycia zależy od głowy programisty (można walnąć form::open() w kontrolerze, ale byłoby to przegięcie).

Hej

Fragment ze strony Kohana:



Według mnie wyjaśnia wszystko

To ja może dodam małe uzupełnienie do poprzednika... Helpery jako metody mogą korzystać tylko z danych przesłanych jej jako argumenty i wewnątrz nie mogą wykonywać żadnych operacji na innych danych, czyli przykładowo nie mogą odwoływać się do bazy danych. W Kohanie próba napisania helpera tak działającego wywali błąd. Dane tylko z argumentów i operowanie na nich jako jedyna forma dozwolona

nie wiem czy w dobrym kierunku idę, ale np. mamy zbiór funkcjonalności które wymagają współdziałania kilku obiektów, to tworzę sobie helpera do tych funkcjonalności ?

Dopóki nie odwołujesz się do tych obiektów wewnątrz metody helpera, to tak. Możesz jedynie przekazywać te obiekty jako argumenty metody, ale nic ponadto. Zresztą spójrz na definicje funkcji w helperach. Kohana ma to bardzo widoczne. Cały helper to obiekt, a jego funkcje to metody statyczne. Dlatego też dobrze nadaje się na wszelkie operacje stringowe, konwertujące, walidujące. Otrzymujesz bowiem pewien zbiór danych, obiekt i masz na nim przeprowadzić ściśle określone operacje wypluwające pewien wynik. Jeśli zamierzasz użyć helpera jako łącznika pomiędzy pewnymi klasami, to tak naprawdę tworzyszpewien interfejs komunikacji, proste API pomiędzy nimi. Czy jest tu sens tworzyć heleper? Nie sądzę. Lepiej odpowiednio formatować wyjścia obiektów tak, by ich odbiór przez inne obiekty był zawsze w określony formacie, co zapobiegnie błędom.
Jeśli jednak masz we wszystkich klasach tę samą funkcjonalność, to możesz próbować przepchnąć ją do helpera. Przykładem takiej funkcjonalności może być walidacja. Możesz stworzyć helper, który waliguje pola o zadanym typie, czego przykładem może być

[PHP] pobierz, plaintext 
echo validation::valid_date($zmienna);
[PHP] pobierz, plaintext 

A jego definicja:

[PHP] pobierz, plaintext 
class Validation {
    public static function valid_date($variable) {
        //tutaj jeszcze sobie zrób sprawdzanie i konwersję ewentualną
    }
}
[PHP] pobierz, plaintext 

Funkcja ta zwróciłaby FALSE w przypadku niezgodności (pomyłka podczas wpisu) a zwalidowaną do określonego formatu datą, niezależnie jak byłaby ona podana, z kropkami, myślnikami, czy w jeszcze inny sposób. Najważniejsze, że nie mogą one korzystać z innych form danych, poza podstawowymi jak array, wewnątrz.

Coooo? A niby dlaczego?

Niby tak ale jak widac implementacji jest wiele.






Dokladnie o to mi chodzilo o takie dzialanie i to na metodach statycznych.




Problem z tym ze u mnie nie ma mozliwosci uzywania PHP w widokach wiec mam maly zonk, i albo zrobie proste wyrazenie regularne ktore bedzie w widoku interpretowalo:




Jako wywolanie metody za pomoca call_user_func_array() ale potem znow to zwolni w parsowaniu widoku gdy bedzie np tworzenie formularza.

Myslze ze dynamiczne formularze jak ten do logowania mozna spokojnie zrobic za pomoca takiego helpera w kontrolerze jednak juz formularz do wysylania postow/komentarzy jest bardziej oczywisty i mysle ze jego stala implementacja w widoku nie zaszkodzi.

Helper to helper - jak nie pomaga, to nie jest helperem
W sf opisują helpery jako funkcje (lub ich zbiór, ale nadal są to funkcje, nie klasy). Klasy też są - np. xTools, które zawierają statyczne metody. Często są dołączane do pluginów, a symfony ma jedną wbudowaną - sfTools
Ja mam kilka helperów, od prostych funkcji typu print_pre() po obsługę pól tablicowych z pgsql.
prosty helper:

[PHP] pobierz, plaintext 
/**
 * Zwraca  wartość w zależności od parzystości $i
 *
 * @param integer $i
 * @param mixed $mFirst
 * @param mixed $mSecond
 * @return mixed
 */
function modulo($i, $mFirst, $mSecond)
{
	if($i%2==0)
	{
		return $mFirst;
	}
	return $mSecond;
}
[PHP] pobierz, plaintext 

i potem jedziemy np. coś takiego:

[PHP] pobierz, plaintext 
<tr class="<?php print modulo($i, 'nieparzysta', 'parzysta'); ?>">
[PHP] pobierz, plaintext 

Jest pomocne? Jest

Pozdrawiam

tak samo mozna napisac helper do wyswietlania linkow na stronie,path helper czy chocby helper do emotek.

@Cysiaczek mozesz dac tez odpowiedz na 2 czesc mojego postu tzn helpery zrobic w widoku napisac mini parser lub wystarcza jako dodatek do komponentow/pluginow ewentualnie bibliotek.

Tak właśnie się robi. Po jakimś czasie masz sporo małych, ale przydatnych narzędzi.
Piszesz, że nie możesz używać php w szablonie... no w dzisiejszych czasach to niezbyt sensowne, bo tzw smarty-way jest w odwrocie (ale bez flame prosze, bez flame)

--edit
Moim zdaniem helperów powinieneś używać tam, gdzie jest przydatny. Czy to jest kontroler czy szablon, to nie gra większej roli.
W SF mnie właśnie wkurzało, że helpery ładowały się dopiero w szablonach, a ja chciałem np ścieżkę obrazka wygenerować już w kontrolerze. Wtedy helper był... nieprzydatny

No to wlasnie uzywac helpery z poziomu kontrolerow i/lub bibliotek lub dodac mozliwosc do widokow za pomoca ktorych bede tylko ladowal helper po czym robil:



I do widoku ta funckja nam zwroci url: index.php/news,show,1

Tylko co jesli bedzie 30 wywolan helperow nie spadnie wydajnosc aplikacji.




Oczywiscie mozliwosc uzywania heleprow w komponentach/pluginach/bibliotekach zostanie.

Wywołanie jakiejś funkcji czy metody, załadowanie dodatkowej klasy to oczywiście dodatkowy narzut na pamięć czy procesor, ale...
1) Jest to tak nikłe, że nie warto szukać optymalizacji tutaj
2) Nie powinno się popadać w skrajność
3) Wydajność aplikacji jest bardzo ważna - ale nie najważniejsza w większości przypadków

Ja nie mowie o wywolaniu w jakims komponencie czy czyms innym:

[PHP] pobierz, plaintext 
 
Loader::Helper('Url');
 
$this -> view -> AddVar('link', Url::MakeUrl('news', 'show', '1'))
 
[PHP] pobierz, plaintext 

Lecz o:

[HTML] pobierz, plaintext 
 
<html>
 
Url::MakeUrl('news', 'show', '1'); // zwraca nam link za pomoca return
 
</html>
 
[HTML] pobierz, plaintext 

Gdzie klasa View za kazdym napotkaniem Klasa::metoda(); wywola funckje dana funkcje(wczesniej trzeba bedzie tylko zaladowac helper do kontrolera by klasa view tego juz nie robila) i przekazywala jej parametry wszystko za pomoca regexp



Ok co do helperow juz rozwiazalem klasa z metodami statycznymi i mozna wykonac tylko z poziomu php w widoku nie ma takiej mozliwosci(jak narazie).

Jednak nasuwa mi sie kolejne pytanie.

Kalendarz,godzina+data,menu i takie proste statyczne rzeczy gdzie powinny sie znajdowac ponoc rozbijanie aplikacji na jak najmniejsze czesci nie jest zbyt dobrym pomyslem, jednak taka prosta i statyczna rzecz ktora nie potrzebuja nawet modelu nie pasuja mi ani do komponentow/pluginow(poniewaz te maja troche wieksza funkcjonalnosc) ani do helperow.

Wiec tak patrzac troche na archiwum pro, fw RAPIDE i symfony zauwazylem nasze piekne i znane Widgety/Aplety czy jak kto woli to nazywac funkcjonalnosc jest taka sama.

Jak dla mnie taki kalendarz(czy inny prosty widget/aplet) powinien miec bardziej ubogi kontroler niz ten od komponentu/pluginu powinien posiadac prosty widok i w kontrolerze dostep tak do max 3 obiektow Lang,Router i Auth i Acl.

I teraz czy taki widget ogolnie powinien posiadac tylko jedna metode np Execute() czy Render() lub moze posiadac ich kilka?

Wtedy z poziomu kontrolera latwo byloby wczytac taki widget ktory zwroci nam kod html by go wstawic np w komponencie panelu user'a:

[PHP] pobierz, plaintext 
 
$this -> view -> Addvar('Calendar', Loader::Widget('Calendar')); // w naszym komponencie Profil potrzebujemy kalendarz wiec go "includujemy".
 
[PHP] pobierz, plaintext 

Co wy na to?

EDIT
Z tego co doczytalem chodzi o Sloty z symfony wywoluje akcje i jej wynik wsadzam do widoku.

Raczej nie są to sloty, a komponenty.

Co do problemu, zrób to tak jak chcesz i jak będzie Ci z tego wygodnie korzystać. Nie ma jedynego poprawnego i słusznego rozwiązania. Każdy będzie Ci polecał swoje ulubione rozwiązanie, a to Ty masz z tego korzystać i Tobie ma być wygodnie i przyjemnie.

A jednak nie komponenty czyli moduly mam zaimplementowane juz u siebie tak samo pluginy jako rozszerzone komponenty, i na dodatek mam filtry czyli obrobka danych komponentow i/lub pluginow.


Jednak mi chodzi o "dodatek" ktory ma mniejsza funkcjonalnosc od komponentow/pluginow czyli nie posiada modelu i innych bajerow.

Zacytuje kawalek posta z jednego tematu:



To samo moge zrobic chcac kombinujac z forward() i zaladowac akcje danego komponentu do glownego layput'u jednak kalendarz , czy zegar nie potrzebuja modelu czy innych bajerow.

Lub inny przyklad mamy komponent logowania ktory potrzebuje model i wszystko inne user sie loguje.

Teraz moge wybrac menu za pomoca komponentu login lub ladowac odpowiedni widget w zaleznosci od praw user'a bo nie kazdy ma takie same menu.

Chodz ten problem rozwiazalem juz w inny sposob.