Pewnego razu Marooned wspomnial o tym aby zrobic cos na wzor modulow czy wtyczek. Tak, aby mozna bylo wybrac czy projekt ma zawierac BugTrackera, dzial "Praca" (to wkrotce) itp. Hmm... ale Maroonedzie, masz pomysl jak to mialoby wygladac (albo ktokolwiek inny?). Ja nie mam pomyslu aby napisac az tak skalowalny system, aby mozna bylo latwo odlaczac forum itp. rzeczy.
0
0
Nie wiem, czy myslimy o tym samym, ale ja widze to rozumiem tak: chcę postawić coyota - wrzucam pliki do katalogu i odpalam powiedzmy http://localhost/coyote/setup.php
Tam mogę sobie wybrać jakieś tam parametry połączenia do bazy, inne ustawienia. Jest też lista typu:
[ ]..
[x] Artykuły
[x] Praca
[x] Kosz
[ ] Bugtracker
Po zatwierdzeniu zmieniam tylko uprawnienia do pliku, by nikt mi tego nie włączył przypadkiem i tyle.
Jak się mylę, poprawcie mnie.
W bazie mogłoby być zapisane, które moduły lub działy są obsługiwane i zależnie od tego - pokazywałby link (np.: do tworzenia artykułów) lub nie.
0
Tak, tak, ale chodzi mi tutaj o bardziej techniczna strone :) Bo myslalem raczej o modulach, takich jakie sa w systemach portalowych (typu Mambo). Czyli struktura tabeli, organizacja katalogow, wymagane pliki do includowania itp.
Hmm... no bo jak: nalezaloby rozdzielic pliki SQL przechowujace strukture tabeli. Te od tabel BugTrackera, od dzialu "Praca" itp... i w zaleznosci od tego co user wybral, dodawac je, prawda?
Przykladowo: modul sluzacy do blokowania robotow czy programow typu Teleport, hmm... to juz trudniejsze? jakos sobie tego nie wyobrazam :) jak to mogloby wygladac. Chyba jakos latwo nie da sie tego zrobic, to musi byc cos w stylu phpbb hacks ;)
0
Mam tylko jedną uwagę: błagam nie wzorujcie się na Mambo!
// A co do włączania - wyłączania modułów - albo niech to będzie poprzez sktypt php [szybsze] albo cacheowane zapytania SQL.
0
Noooooo :)
W końcu jakieś mega pozytywne zmiany [a raczej plany].
Faktem jest, że jedyny taki system od strony technicznej jaki znam, to Mambo. Nie ma on samych minusów, jakby można było wywnioskować z postu Qyona, aczkolwiek jest on przeznaczony do innych celów - u nas chyba niemożliwe by było napisać coś a'la Mambo - tam skórka, to jeden plik php, bez forum...
Niestety, nie wiem jak wyglądają wtyczki do phpBB, IPB :(
Jednak ja bym to widział od strony użytkowej jak w Mambo - czyli każdą wtyczkę można doinstalować, usunąć czy chwilowo wyłączyć w każdej chwili przez admin panel.
Myślę, że .zip z niezbędnymi plikami + opis co do czego w XML to dobry pomysł - dość skalowalny i łatwy w implementacji.
Największy problem jest taki, czy ograniczyć możliwości wtyczek [jak w Mambo] tylko do kilku rzeczy [mogą dodać pewien kod na jakieś strony] czy spróbować wymyślić system, który zezwoli wtyczce całkowicie zmienić funkcjonowanie dowolnej części strony. Chwilowo nie wiem, czy takie coś jest wykonalne...
Fajnie, gdyby ktoś po krótce opisał jak to jest w innych systemach, forach..
Będę myślał.. i liczę na konstruktywną debatę :)
P.S.
A to, o czym napisał Szczawik, to inna para kaloszy - to wybór instalowanych wtyczek przy instalacji - będą wtyczki, będzie wybór przy instalacji - to jasne :)
Marzeniem jest oddzielić stronę główną od forum tak, by można było zainstalować tylko jedno z tego jeśli zajdzie taka potrzeba...
0
Wtyczki do phpBB ja wiem jak wyglądają. Nie istnieją. Wszelkie mody to ręczna modyfikacja odpowiednich plików oryginalnego skryptu.
0
Ktos: Ale zauważ, jak są zrealizowane wtyczki w phpBB mod by Przemo - tam każdą możesz sobie wyłączyć wedle życzenia. Jedną opcją w AdminPanelu.
0
Co do wykonania to ja mam następujący pomysł (bo ostatnio sam nad czymś takim siedzę do strony firmy). Nie testowałem, ale to taka myśl.
Idea jest taka, by stworzyć klasę posiadającą określoną przez użytkownika funkcjonalność (będzie posiadała tylko wybrane operacje) - ideowo będzie to coś takiego:
//////////////////////////////////////////////////////////////////////
// main.php
//////////////////////////////////////////////////////////////////////
class KlasaBazowa
{
..
}
include('kosz.php');
include('praca.php');
$Obiekt = new KlasaPraca; // KlasaPraca bo na samym dole hierarchii
if (method_exists($Obiekt, 'DodajLink_OproznianieKosza'))
DodajLink_OproznianieKosza();
//////////////////////////////////////////////////////////////////////
// kosz.php
//////////////////////////////////////////////////////////////////////
if ($wybrano_kosz)
{
class KlasaKosz extends KlasaBazowa
{
//.. metody Kosza, np.: function DodajLink_OproznianieKosza() { }
}
}
else
{
class KlasaKosz extends KlasaBazowa
{
// bez nowych metod, tylko by zachować hierarchię
}
}
//////////////////////////////////////////////////////////////////////
// praca.php
//////////////////////////////////////////////////////////////////////
if ($wybrano_praca)
{
class KlasaPraca extends KlasaKosz
{
//.. metody Pracy
}
}
else
{
class KlasaPraca extends KlasaKosz
{
// bez nowych metod, tylko by zachować hierarchię
}
}
Taki jest zarys. [soczek]
0
Szczawik napisał(a)
if (method_exists($Obiekt, 'DodajLink_OproznianieKosza'))
DodajLink_OproznianieKosza();
Sorry, ale zalatuje mi tu LLoP - możesz jakoś jaśniej to przedstawić?
0
LLoP? Cokolwiek..
Chodzi mi o to, aby na razie nie tyle dodawać nową funkcjonalność poprzez moduły, co obecną podzielić na moduły i stworzyć klasę, która zawierałaby funkcjonalność użytą przez administratora do stworzenia danej instalacji.
Szablony byłyby tak przerobione, aby wykonać określoną funkcjonalność, tylko, jeśli klasa ją posiada. Rozumiem oczywiście problem, że tu z góry byłoby ustalone, jakie klasa posiada metody, ale to problem do rozpatrzenia.
Może ta klasa pozwoliłaby jakoś wyewoluować w rozszerzalny model modułowy. Nad tym jeszcze rozmyślam. Na przykład nowe moduły dodawałyby się do jakiejś tablicy (tablic) będącej polami tej klasy.
Przyznam, że dodawanie modułów jest trudne, bo należałoby jakoś zdecydować, w którym miejscu dodawany moduł ma "obiawiać swoją obecność" - gdzie wstawić jakiegoś linka, podstronę czy coś takiego.
Pytanie też, jak szeroko kto pojmuje proponowany zakres działania dodawanego modułu.. ?
0
LLoP. Dawno dawno temu to było...
Living Language of Programming czy coś takiego, taka bzudrna idea napisania języka programowania.
Dryobates napisał(a)
LLOP = Life Language Of Programming. Nowa koncepcja programowania. Niestety nie moge pokazac kodu tego programu, niestety jacys brutale usuneli go (chyba, ze ktos ma jakies archiwa i przesle ci). Tak pobieznie to kod wygladal tak (chodzi o sama idee, a nie konkretny kod):
procedure Wykonaj(Polecenie: string);
begin
if Polecenie = 'Wypisz Hello World' then
WypiszHelloWorld;
if Polecenie = 'Wypisz Hello World po polsku' then
WypiszHelloWorldPoPolsku;
if....
end;procedure WypiszHelloWorld;
begin
ShowMessage('Hello World');
end;procedure WypiszHelloWorldPoPolsku;
begin
ShowMessage('Witaj swiecie');
end;
...Niestety nalezaloby to zobaczyc (jak rowniez komentarze i optymalizacje tego kodu )
/* Tylko nie sugerować się, że ja te LLoP wymyśliłem :) - dryo */
0
Nie no, ja użyłem normalnych funkcji, które oferuje PHP. Chodzi mi o coś takiego, by całość przysyłanej do użytkownika strony była generowana przez klasę, które budowa zależałaby od zainstalowanych wtyczek.
Tylko pytanie: czy chcemy pracować nad wersją, w której wtyczki będą już zdefiniowane i damy prawo je wyłączać, czy też wtyczki będą powstawały po stworzeniu strony i jakoś będą musiały umieć się domontować do klasy głównej?
To tylko taka myśl, choć z tego co widzę, częściowo zahaczyłem chyba o ten LLoP :|
0
zastanawia mnie tylko jedno. Dlaczego wyboru wtyczek bedzie mozna dokonywac tylko z poziomy instalacji? Sadze ze trzeba by bylo zaprojektowac system dodawania wtyczek z poziomu panelu admina.
0
A jaka różnica, czy info o wtyczkach zmienisz przy instalacji czy działaniu? To był tylko taki kontekst, ale oczywiście warto móc podcas działania modyfikować, tylko co potem robić z dodanymi już na przykład linkami do działu, który wyłączyłeś?
0
no i tu pojawia sie wtedy problem. choc nie myslalem o wylaczaniu a dodawaniu. Aczkolwiek otworzyles mi oczy na cos co moze sprawic duzo problemow.
0
Zescie pojechali Szczawika jak kolejnego dzieciaka na forum, a to czym zapodal (moze nie swiadomie) probuje nawiazywac do obiektowych wzorcow pisania aplikacji w PHP, ktorych zalety i wady moznaby dlugo wymieniac. Ale coyote to od poczatku zupelnie inna architektura, tutaj trzeba budowac rozwiazania pod to, co juz jest.
0
M. stwierdził, że - tu cytat: "ta dyskusja nie może umrzeć!!", a ja się pod tym podpiszę i postaram dodać coś konstruktywnego.
Po pierwsze: czy zakładamy, że pluginy to elementy powstałe razem za stroną, tylko włączane lub nie, zależnie od instalacji, czy też pluginy to elementy dodawane do strony po jej 'wydaniu' - ze źródeł trzecich?
- rozwiązanie 1 jest łatwe w realizacji, ale mało przyszłościowe
- rozwiązanie 2 jest trudne, ale pozwala na późniejszy rozwój strony (załóżmy, że to wybraliśmy)
Po drugie: jak 'zaczepić' plugin na stronie, gdzie go użyć i ładować? Czy w stronach zrobić w różnych miejscach <font color="darkred">< TAGn ></span> {n to jakiś numer}, a przepytując kolejne pluginy będą one - w miarę własnych potrzeb - coś tam doklejały? Na przykład <font color="darkred">< TAG1 ></span> mógłby oznaczać listę linków na stronie do podstron konfiguracji pluginów. Gdyby plugin1 potrzebował konfiguracji, zwracałby w tym miejscu <font color="darkblue">< a href..1.. > < /a >,</span> kolejny plugin2 zwracałby <font color="darkblue">< a href..2.. > < /a ></span>, plugin3 nie miałby konfiguracji, więc nic by nie dodawał i ostatecznie na stronie byłyby <font color="darkblue">< a href..1.. > < /a >< a href..2.. > < /a ></span>. Podobnie można by <font color="darkred">< TAG2 ></span> dać przy ikonach przy postach, doklejając linkom id postu, na końcu strony postów <font color="darkred">< TAG3 ></span>, tak mogłaby na przykład zostać dodana 'szybka odpowiedź', która zawitała na forum.
Po trzecie: ile takich tagów dać i gdzie?
Po czwarte: w jakiej kolejności przepytywać pluginy?
Po piąte: czy w ogóle dawać tagi, czy rozwiązać to inaczej?
//A zjechaniem się nie przejmuję, może coś z tego dobrego dla dyskusji wyniknie.
//Może zamiast tagów, dać lepiej komentarz o znaczeniu specjalnym <font color="green"></span>
Pluginy mogłyby dodawać siebie przez dopisywanie swej funkcji do tablicy wywoływanych pluginów. Przy trafieniu na specjalny komentarz, engine strony wywoływałby z listy kolejne funkcje, podając im parametr - numer n.
Przykład:
//###########################################
// INDEX.PHP
//###########################################
<?php
//Tablica zainstalowanych pluginow
$pluginy = array('plugin1', 'plugin2');
foreach ($pluginy as $plugin)
include($plugin.'.php');
?>
<HTML>
<BODY>
<?php
//znalaziono w szablonie TAG1: funkcja z 2 parametrami string
foreach ($pluginy as $plugin)
call_user_func($plugin, 1, array('PARAMETR1', 'PARAMERT2'));
?>
<B>STRONA</B></BR>
<?php
//znalaziono w szablonie TAG2: funkcja bez parametrow
foreach ($pluginy as $plugin)
call_user_func($plugin, 2, array());
?>
</BODY>
</HTML>
//###########################################
// PLUGIN1.PHP
//###########################################
<?php
function plugin1($n, $a)
{
if ($n == 1)
{
foreach ($a as $tekst)
print('Plugin1: '.$tekst.'</BR>');
}
else
return $a;
}
?>
//###########################################
// PLUGIN2.PHP
//###########################################
<?php
function plugin2($n, $a)
{
if ($n == 1)
{
foreach ($a as $tekst)
print('Plugin2: '.$tekst.'</BR>');
}
if ($n == 2)
{
print('Plugin2');
}
if ($n == -1)
{
return array(strtolower(implode('', $a)));
}
else
return $a;
}
?>
To rozwiązanie ma i wady i zalety:
- WADY: funkcje pluginów muszą mieć 2 parametry (n, tablica parametrów); muszą mieć takie nazwy jak pliki - aby się nie przysłaniały; nie może być 2 pluginów o tej samej nazwie; dla bogactwa możliwości dodania funkcjonalności będzie potrzebne wiele TAGów w szablonach.
- ZALETY: pluginy mogą reagować tylko tam, gdzie chcą (tu plugin 1 reaguje tylko na TAG1), pluginy mogą mieć różną ilość argumentów przekazywaną, pluginy w danym miejscu mają dużą swobodę i wykonania i wstawiania kodu.
Przydałby się jeszcze mechanizm, by plugin mógł przeładować stronę (np.: linkiem) i przed pokazaniem nowej coś wykonać, ale to już inna sprawa.
To tylko propozycja.
DOPISANE NOWEGO DNIA:
//Przez noc natchnęło mnie trochę, więc już opisuję. Warto, aby podstawiane TAGi były w szablonach, ale także przy samym przetwarzaniu strony - nie w konkretnym miejscu tylko przy konkretnej operacji. Powiedzmy, TAGn w szablonach (n>=0), TAGn wywoływany przy przetwarzaniu (n<0). Jaki z tego zysk?
Choćby taki:
//###########################################
// INDEX.PHP - Wycinek
//###########################################
<?php
//TAG-1 używany jest przy wyswietlaniu postów
$posty = array('POST!');
foreach ($pluginy as $plugin)
{
$posty=call_user_func($plugin, -1, $posty);
}
print(implode('',$posty));
?>
Jeśli w plugin2, zamiast zmniejszać litery przy n=-1, edytowalibyśmy treść, to tak właśnie możemy wydzielić moduły do obrabiania postów (ortografia, kolorowanie, może cenzurowanie czy skracanie linków). Tylko pluginy musiałyby zwracać parametr bez zmian, gdy nie obsługują funkcji danym numerze, by nie powodować znikania treści.
Opcje w profilu użytkowników też możnaby modułować. Powiedzmy po standardowych opcjach, byłby TAG4 powiedzmy, gdzie każdy plugin mógłby dokleić swoje pola edycji parametrów, można określić, że ich nazwy byłyby w stylu plugin2_nazwapola. Po wysłaniu formularza, przed rozpoczęciem przerabiania szablonu, powinien być użyty TAG-4, powiedzmy, a przepytywane pluginy szukałyby w wypostowanych informacjach swoich pól i dopisywały zmiany do bazy czy coś takiego.
Warto porobić założenia, by pluginy nie modyfikowały oryginalnych tabel, najwyżej robiły sobie własne z kluczem obcym i powiązaniem 1:1. Pluginy powinny mieć również funkcję wywoływaną przy instalacji i deinstalacji (najlepiej osobną funkcję, w stylu plugin2_install, plugin2_uninstall).
0
Przydałby się czyjś komentarz do powyższego. Czy to w ogóle ma sens i jak się na to zapatrujecie? Jak nikt się tym nie zainteresuje, to pewnie temat zginie śmiercią głodową.
0
IMO spokojnie wystarczylo by wywolanie pluginu przy rozpoczeciu i zakonczeniu (powiedzmy, ze przed wypluniem szablonu do przegladarki /jego zawartosc byla by dostepna z pluginu/) wykonywania skryptu. Na moje oko takie cos pozwoli na dowolna modyfikacje systemu.
0
Jednak i tak konieczne byłoby oznaczenie miejsc kluczowych (np.: ikon przy postach), bo miejsce to w każdym skinie może wyglądać inaczej.
0
Pozwoli. Pytanie tylko jakim kosztem. Zwróć uwagę, że żadne interfejsy dla wtyczek wszelkich programów nie ograniczają się do przekazania uchwytu procesu i wywołaniu procki w DLL'u, choć formalnie wystarczyłoby to, by się wpiąć gdzie trzeba i coś zrobić. Problem polega na tym, ile trzeba się napracować, by wprowadzić jakąś modyfikację w ten sposób.
0
Adam.Pilorz ~ ale zauwaz tez, ze normalne programy sa zapetlone, reaguja na uzytkownika i takie tam, skrypt dostaje jakies tam parametry, ma cos zrobic (wyslac cos do uzytkownika i/lub zmodyfikowac cos na serwerze /baze czy jakies pliki/) i juz.
0
Nie wczytywałem się jeszcze w posty Szczawika - zrobię to na dniach - problemy z czasem.. ale jeśli plugin mógłby tylko dopisać jakiś link czy tam formularz w kilka miejsc w skórce, to czy pozwoliłoby to na dość dowolne pluginy, które potrafiłyby zmienić w sporym stopniu działanie witryny? Bo jak już coś ma powstać, to żeby było mega funkcjonalne i dość uniwersalne a nie ograniczone do wstawienia linku w kilka wybranych miejsc :)
0
TAGi w określonych miejscach mają pomóc zlokalizować elementy (lokacje) strony, ale nie muszą zastępować jakiejkolwiek jej interpretacji. Wolverine może i miał rację z wczytaniem pluginów tylko dwa razy - przed i po zbudowaniu strony; ale jestem za tym, by po jej zbudowaniu plugin dostawał treść z wplecionymi TAGami oraz tablice parametrów do wykorzystania przy określonych TAGach. (Te parametry mogą się przydać, np.: przekazywać pluginowi ID posta czy użytkownika przy TAGu związanym z postem.)
0
Ożywię ten temat, kierując uwagę w stronę przygotowanych przez Adama Boduach zmian w template.php. Może od razu wziąć pod rozwagę moje powyższe pomysły?
Czekam na komentarze.
0
Ostatnio dyskutowaliśmy z Kapustką na temat pluginów, i mamy kilka pomysłów na zrobienie szkieletu obsługi pluginów. jak będę mieć trochę czasu (uhh... za kilka miesięcy?) to przedstawię co wymyśliliśmy i trochę pogrzebię w kodzie.
Oczywiście o ile Adam nie zrobi tego wcześniej.
0
Chetnie bym ujrzal specyfikacje :)
Ja na razie majstruje w kodzie w zwiazku z grafika, wiele juz mam zrobione, ale jeszcze nie wszystko. Chetnie obejrzalbym specyfikacje tego pomyslu. Nie wiem jednak jaki jest mozliwy, max. poziom skalowalnosci takiego rozwiazania.
Przyklad - wtyczka "download". Umozliwia sciagnie plikow uprzednio wyslanych na serwer, przegladanie zawartosci archiwum.
Zalozenia:
- dziala pod adresem download.4programmers.net
- umozliwia wyszukiwanie oraz integracje z glowna wyszukiwarka serwisu (tak jak jest teraz)
- hmm... np. mozliwosc wyswietlania spisu kilku dzialow w menu (tak jak jest obecnie - sekcja "download")
- wtyczka musi udostepniac tez cos w rodzaju "lacznika", aby np. przez klase mozna bylo pobrac i wyswietlic na stronie glownej spis ostatnio dodanych plikow
Nie mam pomyslu jak zrobic aby to bylo na tyle elastyczne (przyznaje sie ze nie czytalem dokladnie tego watku i pomyslow jakie tu padaly... tzn. watek przeczytalem ale nie analizowalem dokladnie mozliwosci zaimplementowania tego w kodzie).
0
Problem dosyć prosty do rozwiązania. Ja to widzę tak:
- plik xml ze zdefiniowanymi miejscami montowania wtyczek.
- w odpowiednich miejscach kodu odwolanie sie do obiektu kontrolujacego wtyki z przeslaniem nazwy miejsca montowania jako parametru
- w panelu admina mozliwosc dodania wtyczki => nazwa, miejsce zamontowania, kod php do wykonania, kod php instalujacy, kod php odinstalujacy
- wtyczki eksportowane/importowane do/z xml
i teraz kilka przykladow:
plik hooks.xml:
<hooks>
<hook>index_start</hook>
<hook>index_end</hook>
<hook>edit_profile_start</hook>
<hook>memberlist</hook>
</hooks>
plik index.php:
($hook = eval("MenedzerWtyczek:zamontuj('memberlist');");)
metoda zamontuj obiektu MenedzerWtyczek pobiera kod wszystkich wtyczek ktorych miejsce montowania == parametr funkcji i zwraca je, a wtedy zostaje on wykonany przez eval();
Za pomoca czegos takiego mozna zarowno modyfikowac jak i rozszerzac funkcjonalnosc aplikacji.
Przykład, index.php:
$string = 500;
($hook = eval("MenedzerWtyczek:zamontuj('index_costam');");)
echo $string;
wtyczka montowana w index_costam:
$random = rand(4, 10000);
$string = $string + $random;
Zostanie wyswietlony wynik dodawania 50 + losowa liczba z zakresu 4-10000. Oczywiscie mozna tez np. zaincludowac jakis niestandardowy plik i wykonac dana funkcje... eval() nie ma ograniczen ;-)
0
Niestety ma to takie ograniczenie, że instalacja wtyczki będzię wymagała ręcznej modyfikacji oryginalnego pliku.
//dopisane:
W takim razie trzeba by było wywoływać wstawianie co linijkę, aby zmaksymalizować możliwości wtyczek. Inaczej wtyczki będą dość ograniczone. A duża ilość miejsc do wstawienia wtyczek spowoduje na pewno spowonienie Coyote.
Niedawno pisałem taki dość prosty system wtyczek, pozwala on wstawiać w dowolną linię kod, includować pliki a następnie wstawiać funkcję w podane miejsce. Parametry też można podać. Imo jest szybki, ponieważ pliki z zainstalowanymi wtyczkami są trzymane w głównym katalogu. Oryginalne, niezmienione źródła przechowuje w osobnym katalogu.
0
Nie, nie będzie.
Developerzy ustalają miejsca montowania w plikach i tyle. Użytkownik importuje plik .xml z kodem wtyki przez panel admina i na tym kończy się jego robota.
[edited]
<?php
class MenedzerWtyczek
{
function MenedzerWtyczek()
{
}
function pobierz_wtyke($montowanie)
{
return @file_get_contents("wtyka_$montowanie.plg");
}
}
($hook = MenedzerWtyczek::pobierz_wtyke('index')) ? eval($hook) : false;
?>
wtyka_index.plg:
// wyswietli 'aaa50'
$string = 'aaa';
$int = 50;
echo $string . $int;
To oczywiscie przyklad oparty na plikach, zakladajac, ze wtyczki przechowywane bylyby w bazie danych i keszowane, metoda pobierz_wtyke wygladalaby calkiem inaczej. Aha, nie jest to wolne ;-)