W dniu 05.10.2015 13:06, Marcin napisał(a):

no właśnie phpui, plugins. tylko nie "1", tylko wpisz nazwy pluginów oddzielone średnikiem

Można bezpośrednio z interfejsu użytkownika: Konfiguracja->Wtyczki.

W dniu 5 października 2015 13:05 użytkownik Piotr Smoleń komuch@gmail.com napisał:

...

Witam,

W którym miejscu (oprócz phpui.plugins = 1) włącza się pluginy ? W najnowszej wersji GIT, pojawia się opcja "Pluginy" w "Konfiguracja", w tej (wcześniejszej) wersji nie ma tego.

Wrzucam sobie plugin do katalogu, ale nic się nie dzieje.

Z góry dzięki za info.

Pozdrawiam _______________________________________________ lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms

--

Pozdrawiam Marcin / nicraM

---

lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms

W dniu 05.10.2015 o 20:05, Maciej Lew pisze:

W starszych wersjach w phpui.plugins wpisujemy co takiego:

MojPlugin:1;MojInnyPlugin:2

1, 2 itd to priorytet pluginu. Można także sprawdzić czy pluginy są w ogóle obsługiwane w posiadanej wersji LMS, np sprawdzając czy istnieje katalog lib/LMSPluginManager.

W dniu 05.10.2015 o 13:41, Tomasz Chiliński pisze:

...

W dniu 05.10.2015 13:06, Marcin napisał(a):

...

no właśnie phpui, plugins. tylko nie "1", tylko wpisz nazwy pluginów oddzielone średnikiem

Można bezpośrednio z interfejsu użytkownika: Konfiguracja->Wtyczki.

...

W dniu 5 października 2015 13:05 użytkownik Piotr Smoleń komuch@gmail.com napisał:

...

Witam,

W którym miejscu (oprócz phpui.plugins = 1) włącza się pluginy ? W najnowszej wersji GIT, pojawia się opcja "Pluginy" w "Konfiguracja", w tej (wcześniejszej) wersji nie ma tego.

Wrzucam sobie plugin do katalogu, ale nic się nie dzieje.

Z góry dzięki za info.

Pozdrawiam _______________________________________________ lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms

--

Pozdrawiam Marcin / nicraM

---

lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms

Dzięki,

Udało się w ten właśnie sposób. To jest jeszcze chyba ta wersja, która nie ma opcji "Wtyczki" w konfiguracji.

Pozdrawiam

Nazwy uchwytów masz w kodzie są różne w zależności od miejsca 6 paź 2015 16:02 "Ernest" ernest@poczta.tarman.pl napisał(a):

Witam !!!

Próbuję właśnie poprzepisywać swoje "dodatki" na pluginy. Jako, że programista ze mnie dość marny mam pytanie. W jaki sposób definiować "uchwyty" (Handlers)?

Z tego co zrozumiałem, to w poszczególnych modułach są umieszczone wpisy typu "$LMS->executeHook('useradd_validation_before_submit', array('useradd' => $useradd,...." czyli uchwyty są zdefiniowane w silniku skryptu.

Zatem wygląda na to, że jest ich trochę mało.

Dodam, że system "wtyczkowy" szalenie mi się podoba z tego względu, że nie ingeruje bezpośrednio w kod silnika co jest dość problematyczne (co użytkownik to inne potrzeby więc i inne modyfikacje kodu/bazy danych).

Pozdrawiam Michal Szmigielski /ernesttar/ _______________________________________________ lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms

Witam !!! Panie Maćku, dzięki za wyjaśnienie i pomoc!

Zastanawiam się czy nie można w jakiś sposób dodać "automagicznie" ;) hook`ow przynajmniej przed wyświetleniem danego szablonu? Takie cuś załatwiłoby praktycznie wszystkie pluginy dodające coś do wyświetlanej treści.

Druga sprawa to nadpisywanie szablonów. Jeżeli "poprawiamy" dany blok w którym są includy innych plików np. <************************* {extends file="layout.html"} {block name=title}::: LMS :{$layout.pagetitle|striphtml} :::{/block} {block name=module_content} <!--// $Id$ //--> {$xajax} <H1>{$layout.pagetitle}</H1> <TABLE style="width: 100%;"> <TR> <TD style="width: 100%;"> {include file="netdev/netdevinfobox.html"} {*-----ten plik występuje w oryginalnych szablonach i w pluginie----*} ..... <*****************************

i załączany plik ma taką samą nazwę jak istniejący to smarty wyświetla plik oryginalny (taki przynajmniej przypadek był u mnie i jak przypuszczam u kolegi Jarosława /plugin do mikrotika/) W jaki sposób można się przed takim problemem uchronić (poza zmianą nazwy pliku załączanego) ??

Co do innej drogi wykonania zadania to chyba właśnie po to trwają prace nad systemem wtyczek żeby nie trzeba było gmerać w kodzie silnika.

Funkcjonalność która się właśnie przepisuje trochę zmienia podejście do połączeń pomiędzy urządzeniami. Zamiast(albo obok) zapisywania linków ptp bez wyraźnie określonego kierunku dodaję tabelę, w której zapisywane są relacje w stylu wiele do jednego (czyli np switch5 ma port UPLINK(nr np. 1) i łączy się ze switchem3 (na port 5),

przykładowa tabela: netdevid,uplinkport,dstnetdevid,dstport....(tu oczywiście dane linku: typ,prędkość)

pozwala to stworzyć wyraźne drzewo(ścieżkę) połączeń od urządzeń końcowych aż do głównego routera sieci. Czyli będąc na jakimkolwiek urządzeniu jestem w stanie jednoznacznie określić na jakim porcie otrzymuje ono sygnał a na jakich przesyła go dalej. Dodatkowo od najwcześniejszych wersji LMS`a denerwowało mnie "ręczne"(właściwie to pamięciowe) określanie numerów portów w połączeniach dlatego dopisuję do wtyczki okienko ajaxowe na zasadzie wybierania adresu IP.

Jak skończę to jeśli będą chętni podzielę się wynikami ;)

Uff ale się rozpisałem ;)

Pozdrawiam Michal Szmigielski /ernesttar/

W dniu 10/06/2015 o 07:14 PM, Maciej Lew pisze:

Przeszukaj sobie projekt pod kątem występowania metod "executeHook". Nie są one jeszcze dodane w każdym module, raczej zostały dodane tam gdzie komuś opłacało się je dodać. Przejrzenie wszystkich modułów i dodanie hooków to strasznie dużo roboty i raczej nikt tego nie zrobi tylko po to żeby były i czekały aż komuś staną się przydatne. Jeśli potrzebujesz gdzieś hooka gdzie go nie ma to myślę że jak przygotujesz odpowiedniego commita do głównej gałęzi to zostanie on przyjęty.

Istnieje także możliwość że to samo zadanie da się zrobić w inny sposób, bez dodawania hooka. Ale musiałbyś bardziej opisać co chcesz osiągnąć.

W dniu 06.10.2015 o 16:05, Marcin pisze:

...

Nazwy uchwytów masz w kodzie są różne w zależności od miejsca

6 paź 2015 16:02 "Ernest" ernest@poczta.tarman.pl napisał(a):

Witam !!!

Próbuję właśnie poprzepisywać swoje "dodatki" na pluginy.
Jako, że programista ze mnie dość marny mam pytanie.
W jaki sposób definiować "uchwyty" (Handlers)?

Z tego co zrozumiałem, to w poszczególnych modułach są
umieszczone wpisy typu
"$LMS->executeHook('useradd_validation_before_submit',
array('useradd' => $useradd,...."
czyli uchwyty są zdefiniowane w silniku skryptu.

Zatem wygląda na to, że jest ich trochę mało.

Dodam, że system "wtyczkowy" szalenie mi się podoba z tego
względu, że nie ingeruje bezpośrednio w kod silnika co jest dość
problematyczne (co użytkownik to inne potrzeby więc i inne
modyfikacje kodu/bazy danych).

Pozdrawiam
Michal Szmigielski
/ernesttar/
_______________________________________________
lms mailing list
lms@lists.lms.org.pl <mailto:lms@lists.lms.org.pl>
http://lists.lms.org.pl/mailman/listinfo/lms

---

lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms

-- lion.net.pl - wdrożenia i rozwój Lan Management System

---

lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms

Witam !!!

W dniu 10/08/2015 o 12:55 PM, Tomasz Chiliński pisze:

W dniu 08.10.2015 12:50, Ernest napisał(a):

...

Witam !!!

Witam,

...

Panie Maćku, dzięki za wyjaśnienie i pomoc!

Zastanawiam się czy nie można w jakiś sposób dodać "automagicznie" ;) hook`ow przynajmniej przed wyświetleniem danego szablonu? Takie cuś załatwiłoby praktycznie wszystkie pluginy dodające coś do wyświetlanej treści.

Przed wyświetleniem na razie nie ma automatycznych hooków, ale przed ładowaniem już są. Mają nazwę 'nazwaplikuzkatalogumodules_on_load'. Nie widzę w sumie problemu, żeby zrobić automatyczne wywoływanie hooków 'nazwaplikuzkatalogumodules_before_display' - można to byłoby zrobić przez ExecuteHook(...) z metody display() w klasie LMSSmarty, tyle, że moduły zbierają różne informacje przed wywołaniem display(). Chociaż z drugiej strony możemy założyć, że do hooków '*_before_display', byłby przekazywany obiekt $SMARTY, a z takiego obiektu wszystko co zostało ustawione przez assign można odczytać jak również zmienić.

Jestem za ;) U siebie ustawiłem obiekt $SMARTY jako global i funkcją $SMARTY->getTemplateVars('nazwa_zmiennej_z_szablonu'); pobrałem dane przypisane przez $SMARTY->assign() Zauważyłem tylko, że jeżeli zmieniamy coś co było już przypisane do szablonu to należy wywołać jeszcze raz assign() dla tej zmiennej szablonu

...

Druga sprawa to nadpisywanie szablonów. Jeżeli "poprawiamy" dany blok w którym są includy innych plików np. <************************* {extends file="layout.html"} {block name=title}::: LMS :{$layout.pagetitle|striphtml} :::{/block} {block name=module_content}

<!--// $Id$ //-->

{$xajax}

<H1>{$layout.pagetitle}</H1> <TABLE style="width: 100%;"> <TR> <TD style="width: 100%;"> {include file="netdev/netdevinfobox.html"} {*-----ten plik występuje w oryginalnych szablonach i w pluginie----*} ..... <*****************************

i załączany plik ma taką samą nazwę jak istniejący to smarty wyświetla plik oryginalny (taki przynajmniej przypadek był u mnie i jak przypuszczam u kolegi Jarosława /plugin do mikrotika/) W jaki sposób można się przed takim problemem uchronić (poza zmianą nazwy pliku załączanego) ??

Co do innej drogi wykonania zadania to chyba właśnie po to trwają prace nad systemem wtyczek żeby nie trzeba było gmerać w kodzie silnika.

Funkcjonalność która się właśnie przepisuje trochę zmienia podejście do połączeń pomiędzy urządzeniami. Zamiast(albo obok) zapisywania linków ptp bez wyraźnie określonego kierunku dodaję tabelę, w której zapisywane są relacje w stylu wiele do jednego (czyli np switch5 ma port UPLINK(nr np. 1) i łączy się ze switchem3 (na port 5),

przykładowa tabela: netdevid,uplinkport,dstnetdevid,dstport....(tu oczywiście dane linku: typ,prędkość)

pozwala to stworzyć wyraźne drzewo(ścieżkę) połączeń od urządzeń końcowych aż do głównego routera sieci. Czyli będąc na jakimkolwiek urządzeniu jestem w stanie jednoznacznie określić na jakim porcie otrzymuje ono sygnał a na jakich przesyła go dalej. Dodatkowo od najwcześniejszych wersji LMS`a denerwowało mnie "ręczne"(właściwie to pamięciowe) określanie numerów portów w połączeniach dlatego dopisuję do wtyczki okienko ajaxowe na zasadzie wybierania adresu IP.

Jak skończę to jeśli będą chętni podzielę się wynikami ;)

Uff ale się rozpisałem ;)

Pozdrawiam Michal Szmigielski /ernesttar/

W dniu 10/06/2015 o 07:14 PM, Maciej Lew pisze:

...

Przeszukaj sobie projekt pod kątem występowania metod "executeHook". Nie są one jeszcze dodane w każdym module, raczej zostały dodane tam gdzie komuś opłacało się je dodać. Przejrzenie wszystkich modułów i dodanie hooków to strasznie dużo roboty i raczej nikt tego nie zrobi tylko po to żeby były i czekały aż komuś staną się przydatne. Jeśli potrzebujesz gdzieś hooka gdzie go nie ma to myślę że jak przygotujesz odpowiedniego commita do głównej gałęzi to zostanie on przyjęty.

Istnieje także możliwość że to samo zadanie da się zrobić w inny sposób, bez dodawania hooka. Ale musiałbyś bardziej opisać co chcesz osiągnąć.

W dniu 06.10.2015 o 16:05, Marcin pisze:

Nazwy uchwytów masz w kodzie są różne w zależności od miejsca 6 paź 2015 16:02 "Ernest" ernest@poczta.tarman.pl napisał(a):

Witam !!!

Próbuję właśnie poprzepisywać swoje "dodatki" na pluginy. Jako, że programista ze mnie dość marny mam pytanie. W jaki sposób definiować "uchwyty" (Handlers)?

Z tego co zrozumiałem, to w poszczególnych modułach są umieszczone wpisy typu "$LMS->executeHook('useradd_validation_before_submit', array('useradd' => $useradd,...." czyli uchwyty są zdefiniowane w silniku skryptu.

Zatem wygląda na to, że jest ich trochę mało.

Dodam, że system "wtyczkowy" szalenie mi się podoba z tego względu, że nie ingeruje bezpośrednio w kod silnika co jest dość problematyczne (co użytkownik to inne potrzeby więc i inne modyfikacje kodu/bazy danych).

Pozdrawiam Michal Szmigielski /ernesttar/ _______________________________________________ lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms

---

lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms

-- lion.net.pl - wdrożenia i rozwój Lan Management System

---

lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms

---

lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms

W dniu 08.10.2015 13:46, Ernest napisał(a):

Witam !!!

W dniu 10/08/2015 o 12:55 PM, Tomasz Chiliński pisze:

...

W dniu 08.10.2015 12:50, Ernest napisał(a):

...

Witam !!!

Witam,

...

Panie Maćku, dzięki za wyjaśnienie i pomoc!

Zastanawiam się czy nie można w jakiś sposób dodać "automagicznie" ;) hook`ow przynajmniej przed wyświetleniem danego szablonu? Takie cuś załatwiłoby praktycznie wszystkie pluginy dodające coś do wyświetlanej treści.

Przed wyświetleniem na razie nie ma automatycznych hooków, ale przed ładowaniem już są. Mają nazwę 'nazwaplikuzkatalogumodules_on_load'. Nie widzę w sumie problemu, żeby zrobić automatyczne wywoływanie hooków 'nazwaplikuzkatalogumodules_before_display' - można to byłoby zrobić przez ExecuteHook(...) z metody display() w klasie LMSSmarty, tyle, że moduły zbierają różne informacje przed wywołaniem display(). Chociaż z drugiej strony możemy założyć, że do hooków '*_before_display', byłby przekazywany obiekt $SMARTY, a z takiego obiektu wszystko co zostało ustawione przez assign można odczytać jak również zmienić.

Jestem za ;) U siebie ustawiłem obiekt $SMARTY jako global i funkcją $SMARTY->getTemplateVars('nazwa_zmiennej_z_szablonu'); pobrałem dane przypisane przez $SMARTY->assign() Zauważyłem tylko, że jeżeli zmieniamy coś co było już przypisane do szablonu to należy wywołać jeszcze raz assign() dla tej zmiennej szablonu

Może komuś się przyda: https://github.com/lmsgit/lms/commit/4dde09df77f76af75cdcd541af9601547c67f6c... $hook_data w handlerze to obiekt klasy Smarty lub potomnej. Nazwa hooka to nazwamodulu_before_display. Powinno działać dla wszystkich modułów.

...

...

Druga sprawa to nadpisywanie szablonów. Jeżeli "poprawiamy" dany blok w którym są includy innych plików np. <************************* {extends file="layout.html"} {block name=title}::: LMS :{$layout.pagetitle|striphtml} :::{/block} {block name=module_content}

<!--// $Id$ //-->

{$xajax}

<H1>{$layout.pagetitle}</H1> <TABLE style="width: 100%;"> <TR> <TD style="width: 100%;"> {include file="netdev/netdevinfobox.html"} {*-----ten plik występuje w oryginalnych szablonach i w pluginie----*} ..... <*****************************

i załączany plik ma taką samą nazwę jak istniejący to smarty wyświetla plik oryginalny (taki przynajmniej przypadek był u mnie i jak przypuszczam u kolegi Jarosława /plugin do mikrotika/) W jaki sposób można się przed takim problemem uchronić (poza zmianą nazwy pliku załączanego) ??

Co do innej drogi wykonania zadania to chyba właśnie po to trwają prace nad systemem wtyczek żeby nie trzeba było gmerać w kodzie silnika.

Funkcjonalność która się właśnie przepisuje trochę zmienia podejście do połączeń pomiędzy urządzeniami. Zamiast(albo obok) zapisywania linków ptp bez wyraźnie określonego kierunku dodaję tabelę, w której zapisywane są relacje w stylu wiele do jednego (czyli np switch5 ma port UPLINK(nr np. 1) i łączy się ze switchem3 (na port 5),

przykładowa tabela: netdevid,uplinkport,dstnetdevid,dstport....(tu oczywiście dane linku: typ,prędkość)

pozwala to stworzyć wyraźne drzewo(ścieżkę) połączeń od urządzeń końcowych aż do głównego routera sieci. Czyli będąc na jakimkolwiek urządzeniu jestem w stanie jednoznacznie określić na jakim porcie otrzymuje ono sygnał a na jakich przesyła go dalej. Dodatkowo od najwcześniejszych wersji LMS`a denerwowało mnie "ręczne"(właściwie to pamięciowe) określanie numerów portów w połączeniach dlatego dopisuję do wtyczki okienko ajaxowe na zasadzie wybierania adresu IP.

Jak skończę to jeśli będą chętni podzielę się wynikami ;)

Uff ale się rozpisałem ;)

Pozdrawiam Michal Szmigielski /ernesttar/

W dniu 10/06/2015 o 07:14 PM, Maciej Lew pisze:

...

Przeszukaj sobie projekt pod kątem występowania metod "executeHook". Nie są one jeszcze dodane w każdym module, raczej zostały dodane tam gdzie komuś opłacało się je dodać. Przejrzenie wszystkich modułów i dodanie hooków to strasznie dużo roboty i raczej nikt tego nie zrobi tylko po to żeby były i czekały aż komuś staną się przydatne. Jeśli potrzebujesz gdzieś hooka gdzie go nie ma to myślę że jak przygotujesz odpowiedniego commita do głównej gałęzi to zostanie on przyjęty.

Istnieje także możliwość że to samo zadanie da się zrobić w inny sposób, bez dodawania hooka. Ale musiałbyś bardziej opisać co chcesz osiągnąć.

W dniu 06.10.2015 o 16:05, Marcin pisze:

Nazwy uchwytów masz w kodzie są różne w zależności od miejsca 6 paź 2015 16:02 "Ernest" ernest@poczta.tarman.pl napisał(a):

Witam !!!

Próbuję właśnie poprzepisywać swoje "dodatki" na pluginy. Jako, że programista ze mnie dość marny mam pytanie. W jaki sposób definiować "uchwyty" (Handlers)?

Z tego co zrozumiałem, to w poszczególnych modułach są umieszczone wpisy typu "$LMS->executeHook('useradd_validation_before_submit', array('useradd' => $useradd,...." czyli uchwyty są zdefiniowane w silniku skryptu.

Zatem wygląda na to, że jest ich trochę mało.

Dodam, że system "wtyczkowy" szalenie mi się podoba z tego względu, że nie ingeruje bezpośrednio w kod silnika co jest dość problematyczne (co użytkownik to inne potrzeby więc i inne modyfikacje kodu/bazy danych).

Pozdrawiam Michal Szmigielski /ernesttar/ _______________________________________________ lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms

---

lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms

-- lion.net.pl - wdrożenia i rozwój Lan Management System

---

lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms

---

lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms

---

lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms

W dniu 08.10.2015 15:03, Marcin napisał(a):

W dniu 8 października 2015 14:24 użytkownik Tomasz Chiliński tomasz.chilinski@chilan.com napisał:

...

Może komuś się przyda:

https://github.com/lmsgit/lms/commit/4dde09df77f76af75cdcd541af9601547c67f6c...

...

$hook_data w handlerze to obiekt klasy Smarty lub potomnej. Nazwa hooka to nazwamodulu_before_display. Powinno działać dla wszystkich modułów.

dla pewności. Jeśli chcę zarejestrowac jakąś funkcję dla modułu nodes to rejestruje hooka "nodes_before_display" i tak z innymi?

Modułu nodes chyba nie ma? Jeśli założymy, że mamy moduł nodeinfo to rejestrujesz hook: nodeinfo_before_module_display (zmieniłem trochę nazwę, bo pierwotna kolidowała z już istniejącymi *_before_display zindywidualizowanymi dla niektórych modułów).

--

Pozdrawiam Marcin / nicraM

Mówiąc o innych sposobach miałem na myśli wstrzykiwanie zależności w LMS. W tym celu LMS został w większości przerobiony na fasadę dla "managerów". W klasie LMS są specjalne metody pozwalające zastąpić domyślnych managerów własnymi.

W dniu 08.10.2015 o 12:50, Ernest pisze:

Witam !!! Panie Maćku, dzięki za wyjaśnienie i pomoc!

Zastanawiam się czy nie można w jakiś sposób dodać "automagicznie" ;) hook`ow przynajmniej przed wyświetleniem danego szablonu? Takie cuś załatwiłoby praktycznie wszystkie pluginy dodające coś do wyświetlanej treści.

Druga sprawa to nadpisywanie szablonów. Jeżeli "poprawiamy" dany blok w którym są includy innych plików np. <************************* {extends file="layout.html"} {block name=title}::: LMS :{$layout.pagetitle|striphtml} :::{/block} {block name=module_content}

<!--// $Id$ //-->

{$xajax}

<H1>{$layout.pagetitle}</H1> <TABLE style="width: 100%;"> <TR> <TD style="width: 100%;"> {include file="netdev/netdevinfobox.html"} {*-----ten plik występuje w oryginalnych szablonach i w pluginie----*} ..... <*****************************

i załączany plik ma taką samą nazwę jak istniejący to smarty wyświetla plik oryginalny (taki przynajmniej przypadek był u mnie i jak przypuszczam u kolegi Jarosława /plugin do mikrotika/) W jaki sposób można się przed takim problemem uchronić (poza zmianą nazwy pliku załączanego) ??

Co do innej drogi wykonania zadania to chyba właśnie po to trwają prace nad systemem wtyczek żeby nie trzeba było gmerać w kodzie silnika.

Funkcjonalność która się właśnie przepisuje trochę zmienia podejście do połączeń pomiędzy urządzeniami. Zamiast(albo obok) zapisywania linków ptp bez wyraźnie określonego kierunku dodaję tabelę, w której zapisywane są relacje w stylu wiele do jednego (czyli np switch5 ma port UPLINK(nr np. 1) i łączy się ze switchem3 (na port 5),

przykładowa tabela: netdevid,uplinkport,dstnetdevid,dstport....(tu oczywiście dane linku: typ,prędkość)

pozwala to stworzyć wyraźne drzewo(ścieżkę) połączeń od urządzeń końcowych aż do głównego routera sieci. Czyli będąc na jakimkolwiek urządzeniu jestem w stanie jednoznacznie określić na jakim porcie otrzymuje ono sygnał a na jakich przesyła go dalej. Dodatkowo od najwcześniejszych wersji LMS`a denerwowało mnie "ręczne"(właściwie to pamięciowe) określanie numerów portów w połączeniach dlatego dopisuję do wtyczki okienko ajaxowe na zasadzie wybierania adresu IP.

Jak skończę to jeśli będą chętni podzielę się wynikami ;)

Uff ale się rozpisałem ;)

Pozdrawiam Michal Szmigielski /ernesttar/

W dniu 10/06/2015 o 07:14 PM, Maciej Lew pisze:

...

Przeszukaj sobie projekt pod kątem występowania metod "executeHook". Nie są one jeszcze dodane w każdym module, raczej zostały dodane tam gdzie komuś opłacało się je dodać. Przejrzenie wszystkich modułów i dodanie hooków to strasznie dużo roboty i raczej nikt tego nie zrobi tylko po to żeby były i czekały aż komuś staną się przydatne. Jeśli potrzebujesz gdzieś hooka gdzie go nie ma to myślę że jak przygotujesz odpowiedniego commita do głównej gałęzi to zostanie on przyjęty.

Istnieje także możliwość że to samo zadanie da się zrobić w inny sposób, bez dodawania hooka. Ale musiałbyś bardziej opisać co chcesz osiągnąć.

W dniu 06.10.2015 o 16:05, Marcin pisze:

...

Nazwy uchwytów masz w kodzie są różne w zależności od miejsca

6 paź 2015 16:02 "Ernest" ernest@poczta.tarman.pl napisał(a):

Witam !!!

Próbuję właśnie poprzepisywać swoje "dodatki" na pluginy.
Jako, że programista ze mnie dość marny mam pytanie.
W jaki sposób definiować "uchwyty" (Handlers)?

Z tego co zrozumiałem, to w poszczególnych modułach są
umieszczone wpisy typu
"$LMS->executeHook('useradd_validation_before_submit',
array('useradd' => $useradd,...."
czyli uchwyty są zdefiniowane w silniku skryptu.

Zatem wygląda na to, że jest ich trochę mało.

Dodam, że system "wtyczkowy" szalenie mi się podoba z tego
względu, że nie ingeruje bezpośrednio w kod silnika co jest dość
problematyczne (co użytkownik to inne potrzeby więc i inne
modyfikacje kodu/bazy danych).

Pozdrawiam
Michal Szmigielski
/ernesttar/
_______________________________________________
lms mailing list
lms@lists.lms.org.pl <mailto:lms@lists.lms.org.pl>
http://lists.lms.org.pl/mailman/listinfo/lms

---

lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms

-- lion.net.pl - wdrożenia i rozwój Lan Management System

---

lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms

---

lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms

Nie widzę uniwersalnego rozwiązania takiego problemu. Można by mechanizmami refleksji spróbować z wnętrza pluginu sprawdzić czy inny plugin już przesłonił domyślnego managera którego również aktualny plugin chce przesłonić i w jakiś sposób ostrzec użytkownika przed konfliktem.

W dniu 08.10.2015 o 19:03, Tomasz Chiliński pisze:

W dniu 08.10.2015 18:44, Maciej Lew napisał(a):

...

Mówiąc o innych sposobach miałem na myśli wstrzykiwanie zależności w LMS. W tym celu LMS został w większości przerobiony na fasadę dla "managerów". W klasie LMS są specjalne metody pozwalające zastąpić domyślnych managerów własnymi.

Cześć,

w jaki sposób rozwiązujesz kaskadowe (łańcuchowe) tworzenie managerów tak, żeby np. z wielu wtyczek jednocześnie móc modyfikować tego samego managera?

...

W dniu 08.10.2015 o 12:50, Ernest pisze:

...

Witam !!! Panie Maćku, dzięki za wyjaśnienie i pomoc!

Zastanawiam się czy nie można w jakiś sposób dodać "automagicznie" ;) hook`ow przynajmniej przed wyświetleniem danego szablonu? Takie cuś załatwiłoby praktycznie wszystkie pluginy dodające coś do wyświetlanej treści.

Druga sprawa to nadpisywanie szablonów. Jeżeli "poprawiamy" dany blok w którym są includy innych plików np. <************************* {extends file="layout.html"} {block name=title}::: LMS :{$layout.pagetitle|striphtml} :::{/block} {block name=module_content}

<!--// $Id$ //-->

{$xajax}

<H1>{$layout.pagetitle}</H1> <TABLE style="width: 100%;"> <TR> <TD style="width: 100%;"> {include file="netdev/netdevinfobox.html"} {*-----ten plik występuje w oryginalnych szablonach i w pluginie----*} ..... <*****************************

i załączany plik ma taką samą nazwę jak istniejący to smarty wyświetla plik oryginalny (taki przynajmniej przypadek był u mnie i jak przypuszczam u kolegi Jarosława /plugin do mikrotika/) W jaki sposób można się przed takim problemem uchronić (poza zmianą nazwy pliku załączanego) ??

Co do innej drogi wykonania zadania to chyba właśnie po to trwają prace nad systemem wtyczek żeby nie trzeba było gmerać w kodzie silnika.

Funkcjonalność która się właśnie przepisuje trochę zmienia podejście do połączeń pomiędzy urządzeniami. Zamiast(albo obok) zapisywania linków ptp bez wyraźnie określonego kierunku dodaję tabelę, w której zapisywane są relacje w stylu wiele do jednego (czyli np switch5 ma port UPLINK(nr np. 1) i łączy się ze switchem3 (na port 5),

przykładowa tabela: netdevid,uplinkport,dstnetdevid,dstport....(tu oczywiście dane linku: typ,prędkość)

pozwala to stworzyć wyraźne drzewo(ścieżkę) połączeń od urządzeń końcowych aż do głównego routera sieci. Czyli będąc na jakimkolwiek urządzeniu jestem w stanie jednoznacznie określić na jakim porcie otrzymuje ono sygnał a na jakich przesyła go dalej. Dodatkowo od najwcześniejszych wersji LMS`a denerwowało mnie "ręczne"(właściwie to pamięciowe) określanie numerów portów w połączeniach dlatego dopisuję do wtyczki okienko ajaxowe na zasadzie wybierania adresu IP.

Jak skończę to jeśli będą chętni podzielę się wynikami ;)

Uff ale się rozpisałem ;)

Pozdrawiam Michal Szmigielski /ernesttar/

W dniu 10/06/2015 o 07:14 PM, Maciej Lew pisze: Przeszukaj sobie projekt pod kątem występowania metod "executeHook". Nie są one jeszcze dodane w każdym module, raczej zostały dodane tam gdzie komuś opłacało się je dodać. Przejrzenie wszystkich modułów i dodanie hooków to strasznie dużo roboty i raczej nikt tego nie zrobi tylko po to żeby były i czekały aż komuś staną się przydatne. Jeśli potrzebujesz gdzieś hooka gdzie go nie ma to myślę że jak przygotujesz odpowiedniego commita do głównej gałęzi to zostanie on przyjęty.

Istnieje także możliwość że to samo zadanie da się zrobić w inny sposób, bez dodawania hooka. Ale musiałbyś bardziej opisać co chcesz osiągnąć.

W dniu 06.10.2015 o 16:05, Marcin pisze:

Nazwy uchwytów masz w kodzie są różne w zależności od miejsca 6 paź 2015 16:02 "Ernest" ernest@poczta.tarman.pl napisał(a):

Witam !!!

Próbuję właśnie poprzepisywać swoje "dodatki" na pluginy. Jako, że programista ze mnie dość marny mam pytanie. W jaki sposób definiować "uchwyty" (Handlers)?

Z tego co zrozumiałem, to w poszczególnych modułach są umieszczone wpisy typu "$LMS->executeHook('useradd_validation_before_submit', array('useradd' => $useradd,...." czyli uchwyty są zdefiniowane w silniku skryptu.

Zatem wygląda na to, że jest ich trochę mało.

Dodam, że system "wtyczkowy" szalenie mi się podoba z tego względu, że nie ingeruje bezpośrednio w kod silnika co jest dość problematyczne (co użytkownik to inne potrzeby więc i inne modyfikacje kodu/bazy danych).

Pozdrawiam Michal Szmigielski /ernesttar/ _______________________________________________ lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms

---

lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms

-- lion.net.pl - wdrożenia i rozwój Lan Management System

---

lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms

---

lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms

-- lion.net.pl - wdrożenia i rozwój Lan Management System

---

lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms

Co masz przez to na myśli? Odebranie danych z jakiegoś managera i wciśnięcie ich w pętlę hooków? Czy coś innego?

W dniu 08.10.2015 o 19:16, Tomasz Chiliński pisze:

W dniu 08.10.2015 19:11, Maciej Lew napisał(a):

...

Nie widzę uniwersalnego rozwiązania takiego problemu. Można by mechanizmami refleksji spróbować z wnętrza pluginu sprawdzić czy inny plugin już przesłonił domyślnego managera którego również aktualny plugin chce przesłonić i w jakiś sposób ostrzec użytkownika przed konfliktem.

W praktyce okazuje się, że najlepiej realizować kaskadowe zmiany w manager-ach nie przez tworzenie potomnego managera, a kaskadowe/potokowe przetwarzanie wyników.

...

W dniu 08.10.2015 o 19:03, Tomasz Chiliński pisze:

...

W dniu 08.10.2015 18:44, Maciej Lew napisał(a):

...

Mówiąc o innych sposobach miałem na myśli wstrzykiwanie zależności w LMS. W tym celu LMS został w większości przerobiony na fasadę dla "managerów". W klasie LMS są specjalne metody pozwalające zastąpić domyślnych managerów własnymi.

Cześć,

w jaki sposób rozwiązujesz kaskadowe (łańcuchowe) tworzenie managerów tak, żeby np. z wielu wtyczek jednocześnie móc modyfikować tego samego managera?

...

W dniu 08.10.2015 o 12:50, Ernest pisze:

...

Witam !!! Panie Maćku, dzięki za wyjaśnienie i pomoc!

Zastanawiam się czy nie można w jakiś sposób dodać "automagicznie" ;) hook`ow przynajmniej przed wyświetleniem danego szablonu? Takie cuś załatwiłoby praktycznie wszystkie pluginy dodające coś do wyświetlanej treści.

Druga sprawa to nadpisywanie szablonów. Jeżeli "poprawiamy" dany blok w którym są includy innych plików np. <************************* {extends file="layout.html"} {block name=title}::: LMS :{$layout.pagetitle|striphtml} :::{/block} {block name=module_content}

<!--// $Id$ //-->

{$xajax}

<H1>{$layout.pagetitle}</H1> <TABLE style="width: 100%;"> <TR> <TD style="width: 100%;"> {include file="netdev/netdevinfobox.html"} {*-----ten plik występuje w oryginalnych szablonach i w pluginie----*} ..... <*****************************

i załączany plik ma taką samą nazwę jak istniejący to smarty wyświetla plik oryginalny (taki przynajmniej przypadek był u mnie i jak przypuszczam u kolegi Jarosława /plugin do mikrotika/) W jaki sposób można się przed takim problemem uchronić (poza zmianą nazwy pliku załączanego) ??

Co do innej drogi wykonania zadania to chyba właśnie po to trwają prace nad systemem wtyczek żeby nie trzeba było gmerać w kodzie silnika.

Funkcjonalność która się właśnie przepisuje trochę zmienia podejście do połączeń pomiędzy urządzeniami. Zamiast(albo obok) zapisywania linków ptp bez wyraźnie określonego kierunku dodaję tabelę, w której zapisywane są relacje w stylu wiele do jednego (czyli np switch5 ma port UPLINK(nr np. 1) i łączy się ze switchem3 (na port 5),

przykładowa tabela: netdevid,uplinkport,dstnetdevid,dstport....(tu oczywiście dane linku: typ,prędkość)

pozwala to stworzyć wyraźne drzewo(ścieżkę) połączeń od urządzeń końcowych aż do głównego routera sieci. Czyli będąc na jakimkolwiek urządzeniu jestem w stanie jednoznacznie określić na jakim porcie otrzymuje ono sygnał a na jakich przesyła go dalej. Dodatkowo od najwcześniejszych wersji LMS`a denerwowało mnie "ręczne"(właściwie to pamięciowe) określanie numerów portów w połączeniach dlatego dopisuję do wtyczki okienko ajaxowe na zasadzie wybierania adresu IP.

Jak skończę to jeśli będą chętni podzielę się wynikami ;)

Uff ale się rozpisałem ;)

Pozdrawiam Michal Szmigielski /ernesttar/

W dniu 10/06/2015 o 07:14 PM, Maciej Lew pisze: Przeszukaj sobie projekt pod kątem występowania metod "executeHook". Nie są one jeszcze dodane w każdym module, raczej zostały dodane tam gdzie komuś opłacało się je dodać. Przejrzenie wszystkich modułów i dodanie hooków to strasznie dużo roboty i raczej nikt tego nie zrobi tylko po to żeby były i czekały aż komuś staną się przydatne. Jeśli potrzebujesz gdzieś hooka gdzie go nie ma to myślę że jak przygotujesz odpowiedniego commita do głównej gałęzi to zostanie on przyjęty.

Istnieje także możliwość że to samo zadanie da się zrobić w inny sposób, bez dodawania hooka. Ale musiałbyś bardziej opisać co chcesz osiągnąć.

W dniu 06.10.2015 o 16:05, Marcin pisze:

Nazwy uchwytów masz w kodzie są różne w zależności od miejsca 6 paź 2015 16:02 "Ernest" ernest@poczta.tarman.pl napisał(a):

Witam !!!

Próbuję właśnie poprzepisywać swoje "dodatki" na pluginy. Jako, że programista ze mnie dość marny mam pytanie. W jaki sposób definiować "uchwyty" (Handlers)?

Z tego co zrozumiałem, to w poszczególnych modułach są umieszczone wpisy typu "$LMS->executeHook('useradd_validation_before_submit', array('useradd' => $useradd,...." czyli uchwyty są zdefiniowane w silniku skryptu.

Zatem wygląda na to, że jest ich trochę mało.

Dodam, że system "wtyczkowy" szalenie mi się podoba z tego względu, że nie ingeruje bezpośrednio w kod silnika co jest dość problematyczne (co użytkownik to inne potrzeby więc i inne modyfikacje kodu/bazy danych).

Pozdrawiam Michal Szmigielski /ernesttar/ _______________________________________________ lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms

---

lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms

-- lion.net.pl - wdrożenia i rozwój Lan Management System

---

lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms

---

lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms

-- lion.net.pl - wdrożenia i rozwój Lan Management System

---

lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms

Witam !!!

Panie Tomku mam następujące pytanie/propozycję:

Czy w module pluginlist, na liscie dostępnych pluginów dałoby się umieścić przycisk Install/Uninstall i skorelowane z nim hook`i ?

Aktualnie jeżeli plugin nie korzysta ze swoich własnych tabel to w zasadzie wystarczy skopiować go do katalogu z pluginami i włączyć, jeżeli natomiast dochodzą to tego tabele własne wtyczki to przy każdym uruchomieniu trzeba sprawdzać czy wymagane tabele są utworzone i zapewnić korelacje z pozostałymi tabelami.

Akcja install pozwalałaby takie coś przeprowadzić tylko raz na specjalne życzenie. Uninstall podobnie. Chyba, że takowy hook dostępny jest w momencie włączania(aktywacji) pluginu.

Pozostaje w takim wypadku jeszcze ewentualne odinstalowanie wtyczki (skasowanie dodatkowych tabel).

Dodatkowo, oczywiście jeśli pan Tomek nie będzie miał nic przeciwko temu, prośba do wszystkich, którzy piszą własne wtyczki o wzbogacenie oryginalnych plików szablonów (oczywiście tych których dotyczy wtyczka no chyba, że już będą zrobione to wtedy jakikolwiek inny) o bloki ( na wzór vioipaccounts ) i wysłanie ich jako commit`a na git. Myślę, że taka akcja bardzo ułatwi życie nam wszystkim przy pisaniu kolejnych wtyczek.

Osobiście widzę to tak, że dzielimy szablon na jak najmniejsze bloki (nazwapliku-wyróżnik_bloku), dzięki którym wtyczki maja punkt zaczepienia dla swoich danych i nie trzeba rozszerzać głównego pliku tylko fragment o który nam chodzi przez co zmniejsza się niebezpieczeństwo konfliktu pomiędzy wtyczkami. Poniżej przykładowy fragment.

Pozdrawiam Michał Szmigielski /ernesttar/

(fragment pliku "netdev/netdevinfobox.html" wzbogacony o bloki) ..... {if $netdevinfo.model} {block name="netdevinfobox-model"}<!-- dodatkowy znacznik bloku --> <TR> <TD WIDTH="1%"> <IMG SRC="img/netdev_model.gif" ALT=""> </TD> <TD WIDTH="1%"> <B>{trans("Model:")}</B> </TD> <TD WIDTH="98%"> {$netdevinfo.model} </TD> </TR> {/block} {/if} {if $netdevinfo.serialnumber} {block name="netdevinfobox-serial"} <!-- dodatkowy znacznik bloku --> <TR> <TD WIDTH="1%"> <IMG SRC="img/serialnumber.gif" ALT=""> </TD> <TD WIDTH="1%" NOWRAP> <B>{trans("Serial number:")}</B> </TD> <TD WIDTH="98%"> {$netdevinfo.serialnumber} </TD> </TR> {/block} {/if} ...

W dniu 10/08/2015 o 08:15 PM, Tomasz Chiliński pisze:

W dniu 08.10.2015 19:37, Maciej Lew napisał(a):

...

Co masz przez to na myśli? Odebranie danych z jakiegoś managera i wciśnięcie ich w pętlę hooków? Czy coś innego?

Mniej więcej tak.

Witaj Marcinie!!!

Z bardzo prostego powodu, co opiszę na swoim przykładzie. Mam plugin, który dodaje swój kawałeczek do pliku netdevinfobox.html. Kawałeczek, który aż sie prosi o to żeby wstawić go pod kawałkiem (w zasadzie wierszem) netnode. Czyli z drobnymi blokami wstawiam po prostu kolejny wiersz do tabeli.

Bez takiego poszatkowania muszę robić extend do netdevinfo.html i tam podmienić include`a netdevinfobox.html na cokolwiek o innej nazwie bo netdevinfobox.html jest "bezblokowy". Następny plugin, który będzie chciał zrobić tak samo zastąpi moje zmiany i któraś z wtyczek przestanie poprawnie działać. w przypadku kiedy mam duzo bloków to mój kawałek szablonu zamknie się w 8 linijkach, a złożone szablony są i tak cache`owane, więc nie wpłynie to jakoś szczególnie na wydajność.

{extends file="netdev/netdevinfobox.html"} {block name="netdevinfobox-netnode" append} <TR> <TD colspan="2"><b>{trans('Uplink:')}</b></TD> <TD style="">{if $netdevinfo.dstport && $netdevinfo.dstnetdevname}{$netdevinfo.name}({$netdevinfo.uplinkport}) <IMG SRC="img/netdev_takenports.gif" ALT=""> <A HREF=?m=netdevinfo&id={$netdevinfo.dstnetdevid}> {$netdevinfo.dstnetdevname} </A> ({$netdevinfo.dstport}){else}{trans('Unlinked!!!')}{/if}</TD> </TR> {/block}

W dniu 11/06/2015 o 01:44 PM, Marcin pisze:

W dniu 6 listopada 2015 13:39 użytkownik Ernest <ernest@poczta.tarman.pl mailto:ernest@poczta.tarman.pl> napisał:

Dodatkowo, oczywiście jeśli pan Tomek nie będzie miał nic
przeciwko temu,
prośba do wszystkich, którzy piszą własne wtyczki o wzbogacenie
oryginalnych plików szablonów
(oczywiście tych których dotyczy wtyczka no chyba, że już będą
zrobione to wtedy jakikolwiek inny)
o bloki ( na wzór vioipaccounts ) i wysłanie ich jako commit`a na git.
Myślę, że taka akcja bardzo ułatwi życie nam wszystkim przy
pisaniu kolejnych wtyczek.

Osobiście widzę to tak, że dzielimy szablon na jak najmniejsze
bloki (nazwapliku-wyróżnik_bloku),
dzięki którym wtyczki maja punkt zaczepienia dla swoich danych i
nie trzeba rozszerzać głównego pliku tylko fragment o który nam
chodzi przez co zmniejsza się niebezpieczeństwo konfliktu pomiędzy
wtyczkami.
Poniżej przykładowy fragment.

Możesz wyjaśnić po co aż tyle bloków? moim zdaniem jest to zbędne. Oczywiście, jeden blok o nazwie pluginy mógłby być ale nie koniecznie. smarty ma coś takiego jak append, prepend, parent i to wystarczy. możesz dorzucić co kolwiek do bloku już istniejącego bez ingerencji w kod główny.

Pozdrawiam
Michał Szmigielski
/ernesttar/

(fragment pliku "netdev/netdevinfobox.html" wzbogacony o bloki)
.....
      {if $netdevinfo.model}
      {block name="netdevinfobox-model"}<!-- dodatkowy znacznik
bloku -->
        <TR>
                <TD WIDTH="1%">
                        <IMG SRC="img/netdev_model.gif" ALT="">
                </TD>
                <TD WIDTH="1%">
<B>{trans("Model:")}</B>
                </TD>
                <TD WIDTH="98%">
                        {$netdevinfo.model}
                </TD>
        </TR>
        {/block}
        {/if}
        {if $netdevinfo.serialnumber}
        {block name="netdevinfobox-serial"} <!-- dodatkowy
znacznik bloku -->
        <TR>
                <TD WIDTH="1%">
                        <IMG SRC="img/serialnumber.gif" ALT="">
                </TD>
                <TD WIDTH="1%" NOWRAP>
                        <B>{trans("Serial number:")}</B>
                </TD>
                <TD WIDTH="98%">
                        {$netdevinfo.serialnumber}
                </TD>
        </TR>
        {/block}
        {/if}
    ...




W dniu 10/08/2015 o 08:15 PM, Tomasz Chiliński pisze:

    W dniu 08.10.2015 19:37, Maciej Lew napisał(a):

        Co masz przez to na myśli? Odebranie danych z jakiegoś
        managera i
        wciśnięcie ich w pętlę hooków? Czy coś innego?


    Mniej więcej tak.



_______________________________________________
lms mailing list
lms@lists.lms.org.pl <mailto:lms@lists.lms.org.pl>
http://lists.lms.org.pl/mailman/listinfo/lms

-- Pozdrawiam Marcin / nicraM

---

lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms

W dniu 11/06/2015 o 02:07 PM, Marcin pisze:

Dodałem kilka regionów z blokami puściłem pull requesta, jak Tomek

zaakceptuje to może starczy.

Nie chodzi tu o to, żeby ktoś specjalnie siedział nad szablonami i je poprawiał. Teraz mam już gotowe, tylko że zrobione zgodnie ze wzorem na samym dole. Sam mogę zrobić pull request ;) Podpytuję tylko głównodowodzących czy takie podejście ma sens bo jeżeli nie to muszę znaleźć inną drogę do celu (choćby przepisanie szablonów tylko dla siebie).

W dniu 6 listopada 2015 13:59 użytkownik Ernest <ernest@poczta.tarman.pl mailto:ernest@poczta.tarman.pl> napisał:

Witaj Marcinie!!!

Witaj, ale czemu z wykrzyknikami???

To wszystko z sympatii ;)

Z bardzo prostego powodu, co
opiszę na swoim przykładzie.
Mam plugin, który dodaje swój kawałeczek do pliku netdevinfobox.html.
Kawałeczek, który aż sie prosi o to żeby wstawić go pod kawałkiem
(w zasadzie wierszem) netnode.

Tu akurat nie potrzebujesz dodatkowego bloku, załatwiasz to z plugina i smarty.

Czyli z drobnymi blokami wstawiam po prostu kolejny wiersz do tabeli.

Bez takiego poszatkowania muszę robić extend do netdevinfo.html i
tam podmienić include`a netdevinfobox.html na cokolwiek o innej
nazwie bo netdevinfobox.html jest "bezblokowy".

no tak, netdevinfobox.html jest bez bloków, ale ja bym do niego nie wstawiał bloków, bardziej do netdevinfo.html gdzie załatwione byłoby to w jednym pliku.

Następny plugin, który będzie chciał zrobić tak samo zastąpi moje
zmiany i któraś z wtyczek przestanie poprawnie działać.

no nie, wcale tak nie jest. będzie się liczyła kolejność pluginów i smarty do jednego bloku będzie appendował. oczywiście jak będziesz mu kazał tak ze swojego bloku. http://www.smarty.net/docs/en/language.function.block.tpl

w przypadku kiedy mam duzo bloków to mój kawałek szablonu zamknie
się w 8 linijkach,
a złożone szablony są i tak cache`owane, więc nie wpłynie to jakoś
szczególnie na wydajność.

:)

Jako głębiej siedzący w szablonach SMARTY masz większą wiedzę na to co można i jak to wpływa na wydajność. Sam nie robiłem pomiarów zresztą nie byłyby miarodajne na moim dość mocno obciążonym sprzęciku ;(.

{extends file="netdev/netdevinfobox.html"}
{block name="netdevinfobox-netnode" append}
        <TR>
            <TD colspan="2"><b>{trans('Uplink:')}</b></TD>
            <TD style="">{if $netdevinfo.dstport &&
$netdevinfo.dstnetdevname}{$netdevinfo.name
<http://netdevinfo.name>}({$netdevinfo.uplinkport}) <IMG
SRC="img/netdev_takenports.gif" ALT=""> <A
HREF=?m=netdevinfo&id={$netdevinfo.dstnetdevid}>
{$netdevinfo.dstnetdevname} </A>
({$netdevinfo.dstport}){else}{trans('Unlinked!!!')}{/if}</TD>
        </TR>
{/block}



W dniu 11/06/2015 o 01:44 PM, Marcin pisze:

...

W dniu 6 listopada 2015 13:39 użytkownik Ernest
<ernest@poczta.tarman.pl <mailto:ernest@poczta.tarman.pl>> napisał:

    Dodatkowo, oczywiście jeśli pan Tomek nie będzie miał nic
    przeciwko temu,
    prośba do wszystkich, którzy piszą własne wtyczki o
    wzbogacenie oryginalnych plików szablonów
    (oczywiście tych których dotyczy wtyczka no chyba, że już
    będą zrobione to wtedy jakikolwiek inny)
    o bloki ( na wzór vioipaccounts ) i wysłanie ich jako
    commit`a na git.
    Myślę, że taka akcja bardzo ułatwi życie nam wszystkim przy
    pisaniu kolejnych wtyczek.

    Osobiście widzę to tak, że dzielimy szablon na jak
    najmniejsze bloki (nazwapliku-wyróżnik_bloku),
    dzięki którym wtyczki maja punkt zaczepienia dla swoich
    danych i nie trzeba rozszerzać głównego pliku tylko fragment
    o który nam chodzi przez co zmniejsza się niebezpieczeństwo
    konfliktu pomiędzy wtyczkami.
    Poniżej przykładowy fragment.



Możesz wyjaśnić po co aż tyle bloków? moim zdaniem jest to
zbędne. Oczywiście, jeden blok o nazwie pluginy mógłby być ale
nie koniecznie.
smarty ma coś takiego jak append, prepend, parent i to wystarczy.
możesz dorzucić co kolwiek do bloku już istniejącego bez
ingerencji w kod główny.


    Pozdrawiam
    Michał Szmigielski
    /ernesttar/

    (fragment pliku "netdev/netdevinfobox.html" wzbogacony o bloki)
    .....
          {if $netdevinfo.model}
          {block name="netdevinfobox-model"}<!-- dodatkowy
    znacznik bloku -->
            <TR>
                    <TD WIDTH="1%">
                            <IMG SRC="img/netdev_model.gif" ALT="">
                    </TD>
                    <TD WIDTH="1%">
    <B>{trans("Model:")}</B>
                    </TD>
                    <TD WIDTH="98%">
    {$netdevinfo.model}
                    </TD>
            </TR>
            {/block}
            {/if}
            {if $netdevinfo.serialnumber}
            {block name="netdevinfobox-serial"} <!-- dodatkowy
    znacznik bloku -->
            <TR>
                    <TD WIDTH="1%">
                            <IMG SRC="img/serialnumber.gif" ALT="">
                    </TD>
                    <TD WIDTH="1%" NOWRAP>
    <B>{trans("Serial number:")}</B>
                    </TD>
                    <TD WIDTH="98%">
    {$netdevinfo.serialnumber}
                    </TD>
            </TR>
            {/block}
            {/if}
        ...




    W dniu 10/08/2015 o 08:15 PM, Tomasz Chiliński pisze:

        W dniu 08.10.2015 19:37, Maciej Lew napisał(a):

            Co masz przez to na myśli? Odebranie danych z
            jakiegoś managera i
            wciśnięcie ich w pętlę hooków? Czy coś innego?


        Mniej więcej tak.



    _______________________________________________
    lms mailing list
    lms@lists.lms.org.pl <mailto:lms@lists.lms.org.pl>
    http://lists.lms.org.pl/mailman/listinfo/lms




-- 
Pozdrawiam
Marcin / nicraM


_______________________________________________
lms mailing list
lms@lists.lms.org.pl  <mailto:lms@lists.lms.org.pl>
http://lists.lms.org.pl/mailman/listinfo/lms

_______________________________________________
lms mailing list
lms@lists.lms.org.pl <mailto:lms@lists.lms.org.pl>
http://lists.lms.org.pl/mailman/listinfo/lms

-- Pozdrawiam Marcin / nicraM

---

lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms

W dniu 11/06/2015 o 02:45 PM, Marcin pisze:

W dniu 6 listopada 2015 14:37 użytkownik Ernest <ernest@poczta.tarman.pl mailto:ernest@poczta.tarman.pl> napisał:

W dniu 11/06/2015 o 02:07 PM, Marcin pisze:
>Dodałem kilka regionów z blokami puściłem pull requesta, jak
Tomek zaakceptuje to może starczy.

Nie chodzi tu o to, żeby ktoś specjalnie siedział nad szablonami i
je poprawiał.

Aczkolwiek racja. netdevinfo był bezblokowy, więc co za problem na przyszłość ułatwić innym życie?

Teraz mam już gotowe, tylko że zrobione zgodnie ze wzorem na samym
dole.
Sam mogę zrobić pull request ;)

To czemu nie robisz?

Poszły 2 szt. reszta jak skończę przepisywać wtyczkę ;)

Mam jeszcze pytanko. Chciałbym uzależnić sposób wyświetlania danego bloku od zawartości config.phpui w takim sensie, że np. jeżeli phpui.xxx == 1 to zamieniam blok jeżeli phpui.xxx == 2 to dopisujemy dodatkowa treść do oryginału przez block append

Jak to rozwiązać ?? kombinowałem z : {if warunekdospelnienia} {block name=xxx} zawartosc nowego blooku {/block} {else} {block name=xxx append} zawartosc nowego bloku {/block} {/if}

Podpytuję tylko głównodowodzących czy takie podejście ma sens bo
jeżeli nie to muszę znaleźć inną drogę do celu (choćby przepisanie
szablonów tylko dla siebie).

...

W dniu 6 listopada 2015 13:59 użytkownik Ernest
<ernest@poczta.tarman.pl <mailto:ernest@poczta.tarman.pl>> napisał:

    Witaj Marcinie!!!


Witaj, ale czemu z wykrzyknikami???

To wszystko z sympatii ;)

...

    Z bardzo prostego powodu, co
    opiszę na swoim przykładzie.
    Mam plugin, który dodaje swój kawałeczek do pliku
    netdevinfobox.html.
    Kawałeczek, który aż sie prosi o to żeby wstawić go pod
    kawałkiem (w zasadzie wierszem) netnode.


Tu akurat nie potrzebujesz dodatkowego bloku, załatwiasz to z
plugina i smarty.

    Czyli z drobnymi blokami wstawiam po prostu kolejny wiersz do
    tabeli.

    Bez takiego poszatkowania muszę robić extend do
    netdevinfo.html i tam podmienić include`a netdevinfobox.html
    na cokolwiek o innej nazwie bo netdevinfobox.html jest
    "bezblokowy".


no tak, netdevinfobox.html jest bez bloków, ale ja bym do niego
nie wstawiał bloków, bardziej do netdevinfo.html gdzie załatwione
byłoby to w jednym pliku.

    Następny plugin, który będzie chciał zrobić tak samo zastąpi
    moje zmiany i któraś z wtyczek przestanie poprawnie działać.


no nie, wcale tak nie jest. będzie się liczyła kolejność pluginów
i smarty do jednego bloku będzie appendował. oczywiście jak
będziesz mu kazał tak ze swojego bloku.
http://www.smarty.net/docs/en/language.function.block.tpl

    w przypadku kiedy mam duzo bloków to mój kawałek szablonu
    zamknie się w 8 linijkach,
    a złożone szablony są i tak cache`owane, więc nie wpłynie to
    jakoś szczególnie na wydajność.



:)

Jako głębiej siedzący w szablonach SMARTY masz większą wiedzę na
to co można i jak to wpływa na wydajność. Sam nie robiłem pomiarów
zresztą nie byłyby miarodajne na moim dość mocno obciążonym
sprzęciku ;(.

...

    {extends file="netdev/netdevinfobox.html"}
    {block name="netdevinfobox-netnode" append}
            <TR>
                <TD colspan="2"><b>{trans('Uplink:')}</b></TD>
                <TD style="">{if $netdevinfo.dstport &&
    $netdevinfo.dstnetdevname}{$netdevinfo.name
    <http://netdevinfo.name>}({$netdevinfo.uplinkport}) <IMG
    SRC="img/netdev_takenports.gif" ALT=""> <A
    HREF=?m=netdevinfo&id={$netdevinfo.dstnetdevid}>
    {$netdevinfo.dstnetdevname} </A>
    ({$netdevinfo.dstport}){else}{trans('Unlinked!!!')}{/if}</TD>
            </TR>
    {/block}



    W dniu 11/06/2015 o 01:44 PM, Marcin pisze:

...

    W dniu 6 listopada 2015 13:39 użytkownik Ernest
    <ernest@poczta.tarman.pl <mailto:ernest@poczta.tarman.pl>>
    napisał:

        Dodatkowo, oczywiście jeśli pan Tomek nie będzie miał
        nic przeciwko temu,
        prośba do wszystkich, którzy piszą własne wtyczki o
        wzbogacenie oryginalnych plików szablonów
        (oczywiście tych których dotyczy wtyczka no chyba, że
        już będą zrobione to wtedy jakikolwiek inny)
        o bloki ( na wzór vioipaccounts ) i wysłanie ich jako
        commit`a na git.
        Myślę, że taka akcja bardzo ułatwi życie nam wszystkim
        przy pisaniu kolejnych wtyczek.

        Osobiście widzę to tak, że dzielimy szablon na jak
        najmniejsze bloki (nazwapliku-wyróżnik_bloku),
        dzięki którym wtyczki maja punkt zaczepienia dla swoich
        danych i nie trzeba rozszerzać głównego pliku tylko
        fragment o który nam chodzi przez co zmniejsza się
        niebezpieczeństwo konfliktu pomiędzy wtyczkami.
        Poniżej przykładowy fragment.



    Możesz wyjaśnić po co aż tyle bloków? moim zdaniem jest to
    zbędne. Oczywiście, jeden blok o nazwie pluginy mógłby być
    ale nie koniecznie.
    smarty ma coś takiego jak append, prepend, parent i to
    wystarczy. możesz dorzucić co kolwiek do bloku już
    istniejącego bez ingerencji w kod główny.


        Pozdrawiam
        Michał Szmigielski
        /ernesttar/

        (fragment pliku "netdev/netdevinfobox.html" wzbogacony o
        bloki)
        .....
              {if $netdevinfo.model}
              {block name="netdevinfobox-model"}<!-- dodatkowy
        znacznik bloku -->
                <TR>
                        <TD WIDTH="1%">
        <IMG SRC="img/netdev_model.gif" ALT="">
        </TD>
                        <TD WIDTH="1%">
        <B>{trans("Model:")}</B>
        </TD>
                        <TD WIDTH="98%">
        {$netdevinfo.model}
        </TD>
                </TR>
                {/block}
                {/if}
                {if $netdevinfo.serialnumber}
                {block name="netdevinfobox-serial"} <!--
        dodatkowy znacznik bloku -->
                <TR>
                        <TD WIDTH="1%">
        <IMG SRC="img/serialnumber.gif" ALT="">
        </TD>
                        <TD WIDTH="1%" NOWRAP>
        <B>{trans("Serial number:")}</B>
        </TD>
                        <TD WIDTH="98%">
        {$netdevinfo.serialnumber}
        </TD>
                </TR>
                {/block}
                {/if}
            ...




        W dniu 10/08/2015 o 08:15 PM, Tomasz Chiliński pisze:

            W dniu 08.10.2015 19:37, Maciej Lew napisał(a):

                Co masz przez to na myśli? Odebranie danych z
                jakiegoś managera i
                wciśnięcie ich w pętlę hooków? Czy coś innego?


            Mniej więcej tak.



        _______________________________________________
        lms mailing list
        lms@lists.lms.org.pl <mailto:lms@lists.lms.org.pl>
        http://lists.lms.org.pl/mailman/listinfo/lms




    -- 
    Pozdrawiam
    Marcin / nicraM


    _______________________________________________
    lms mailing list
    lms@lists.lms.org.pl  <mailto:lms@lists.lms.org.pl>
    http://lists.lms.org.pl/mailman/listinfo/lms

    _______________________________________________
    lms mailing list
    lms@lists.lms.org.pl <mailto:lms@lists.lms.org.pl>
    http://lists.lms.org.pl/mailman/listinfo/lms




-- 
Pozdrawiam
Marcin / nicraM


_______________________________________________
lms mailing list
lms@lists.lms.org.pl  <mailto:lms@lists.lms.org.pl>
http://lists.lms.org.pl/mailman/listinfo/lms

_______________________________________________
lms mailing list
lms@lists.lms.org.pl <mailto:lms@lists.lms.org.pl>
http://lists.lms.org.pl/mailman/listinfo/lms

-- Pozdrawiam Marcin / nicraM

---

lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms

W dniu 11/06/2015 o 03:51 PM, Marcin pisze:

W dniu 6 listopada 2015 15:37 użytkownik Ernest <ernest@poczta.tarman.pl mailto:ernest@poczta.tarman.pl> napisał:

W dniu 11/06/2015 o 02:45 PM, Marcin pisze:

...

W dniu 6 listopada 2015 14:37 użytkownik Ernest
<ernest@poczta.tarman.pl <mailto:ernest@poczta.tarman.pl>> napisał:


    W dniu 11/06/2015 o 02:07 PM, Marcin pisze:
    >Dodałem kilka regionów z blokami puściłem pull requesta, jak
    Tomek zaakceptuje to może starczy.

    Nie chodzi tu o to, żeby ktoś specjalnie siedział nad
    szablonami i je poprawiał.


Aczkolwiek racja. netdevinfo był bezblokowy, więc co za problem
na przyszłość ułatwić innym życie?

    Teraz mam już gotowe, tylko że zrobione zgodnie ze wzorem na
    samym dole.
    Sam mogę zrobić pull request ;)


To czemu nie robisz?

Poszły 2 szt. reszta jak skończę przepisywać wtyczkę ;)

Mam jeszcze pytanko.
Chciałbym uzależnić sposób wyświetlania danego bloku od zawartości
config.phpui
w takim sensie, że np.
jeżeli phpui.xxx == 1 to zamieniam blok
jeżeli phpui.xxx == 2 to dopisujemy dodatkowa treść do oryginału
przez block append

Jak to rozwiązać ??
kombinowałem z :
    {if warunekdospelnienia}
        {block name=xxx}
            zawartosc nowego blooku
        {/block}
    {else}
        {block name=xxx append}
              zawartosc nowego bloku
        {/block}
    {/if}

a nie lepiej ten warunek rozwiązać w php i przekazać wynik do smarty?

A w jaki sposób ten warunek rozwiązać w pluginie gdzie wynik ma skutkować tylko i wyłącznie zmianą wyświetlania danego bloku ? Tak naprawdę to chodzi o magiczną opcję "append" dodawaną do interesującego mnie bloku. Składnia w przykładzie (z tym, że append był w spełnionym warunku czyli u góry) dawała w wyniku 2x zawartość nowego bloku niezależnie od tego czy if był spełniony czy nie. Może sposobem na takie cuś byłaby sekcja ({section}) ?

Możesz też przygotować dwa pliki html i w zależności od warunku w php wyświetlać odpowiedni plik. 6 lis 2015 16:05 "Ernest" ernest@poczta.tarman.pl napisał(a):

W dniu 11/06/2015 o 03:51 PM, Marcin pisze:

W dniu 6 listopada 2015 15:37 użytkownik Ernest ernest@poczta.tarman.pl napisał:

...

W dniu 11/06/2015 o 02:45 PM, Marcin pisze:

W dniu 6 listopada 2015 14:37 użytkownik Ernest ernest@poczta.tarman.pl napisał:

...

W dniu 11/06/2015 o 02:07 PM, Marcin pisze:

...

Dodałem kilka regionów z blokami puściłem pull requesta, jak Tomek

zaakceptuje to może starczy.

Nie chodzi tu o to, żeby ktoś specjalnie siedział nad szablonami i je poprawiał.

Aczkolwiek racja. netdevinfo był bezblokowy, więc co za problem na przyszłość ułatwić innym życie?

...

Teraz mam już gotowe, tylko że zrobione zgodnie ze wzorem na samym dole. Sam mogę zrobić pull request ;)

To czemu nie robisz?

Poszły 2 szt. reszta jak skończę przepisywać wtyczkę ;)

Mam jeszcze pytanko. Chciałbym uzależnić sposób wyświetlania danego bloku od zawartości config.phpui w takim sensie, że np. jeżeli phpui.xxx == 1 to zamieniam blok jeżeli phpui.xxx == 2 to dopisujemy dodatkowa treść do oryginału przez block append

Jak to rozwiązać ?? kombinowałem z : {if warunekdospelnienia} {block name=xxx} zawartosc nowego blooku {/block} {else} {block name=xxx append} zawartosc nowego bloku {/block} {/if}

a nie lepiej ten warunek rozwiązać w php i przekazać wynik do smarty?

A w jaki sposób ten warunek rozwiązać w pluginie gdzie wynik ma skutkować tylko i wyłącznie zmianą wyświetlania danego bloku ? Tak naprawdę to chodzi o magiczną opcję "append" dodawaną do interesującego mnie bloku. Składnia w przykładzie (z tym, że append był w spełnionym warunku czyli u góry) dawała w wyniku 2x zawartość nowego bloku niezależnie od tego czy if był spełniony czy nie. Może sposobem na takie cuś byłaby sekcja ({section}) ?

---

lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms

W dniu 9 listopada 2015 10:13 użytkownik Ernest ernest@poczta.tarman.pl napisał:

Witaj Marcinie.(skoro nie lubisz wykrzykników to kropka ;) )

:))

Ja się nie upieram żeby zrobić to w smarty. Jest zdefiniowany szablon z blokiem i teraz w zależności od zawartości phpui potrzebuję wyświetlić albo oryginalny blok, albo nowy, albo obydwa.

pytanie. czy w ogóle "dotykasz" plik /modules/X.php z core? czy tworzysz swoje. bo lms najpierw szuka w katalogu modules pluginu, a jak go nie ma to w katalogu core, tak samo z displayem. tu trzeba pomyśleć, co konkretnie robisz i jaki chcesz mieć efekt? bo cały czas piszesz o .html, ale nie wiemy z jakiego poziomu to wywołujesz.

Jeśli jest sposób żeby zrobić to z poziomu plugina to proszę o podpowiedz.

Tu nie chodzi o sposób z poziomu plugina, lecz plików które są wpierw czytane i co robią.

Po weekendowej przerwie przychodzi mi jeszcze do głowy pomysł (oparty jednak na smarty) z funkcją {capture} (gdzies na listach coś takiego wyszukałem)

Nigdy nie używałem tej funkcji :) i nie widzę tak na szybko by rozwiązać Twój problem z tą wiedzą, którą przedstawiłeś.

Pozdrawiam /ernesttar/ W dniu 11/06/2015 o 05:15 PM, Marcin pisze:

Możesz też przygotować dwa pliki html i w zależności od warunku w php wyświetlać odpowiedni plik. 6 lis 2015 16:05 "Ernest" ernest@poczta.tarman.pl napisał(a):

...

W dniu 11/06/2015 o 03:51 PM, Marcin pisze:

W dniu 6 listopada 2015 15:37 użytkownik Ernest ernest@poczta.tarman.pl napisał:

...

W dniu 11/06/2015 o 02:45 PM, Marcin pisze:

W dniu 6 listopada 2015 14:37 użytkownik Ernest <ernest@poczta.tarman.pl

...

napisał:

...

W dniu 11/06/2015 o 02:07 PM, Marcin pisze:

...

Dodałem kilka regionów z blokami puściłem pull requesta, jak Tomek

zaakceptuje to może starczy.

Nie chodzi tu o to, żeby ktoś specjalnie siedział nad szablonami i je poprawiał.

Aczkolwiek racja. netdevinfo był bezblokowy, więc co za problem na przyszłość ułatwić innym życie?

...

Teraz mam już gotowe, tylko że zrobione zgodnie ze wzorem na samym dole. Sam mogę zrobić pull request ;)

To czemu nie robisz?

Poszły 2 szt. reszta jak skończę przepisywać wtyczkę ;)

Mam jeszcze pytanko. Chciałbym uzależnić sposób wyświetlania danego bloku od zawartości config.phpui w takim sensie, że np. jeżeli phpui.xxx == 1 to zamieniam blok jeżeli phpui.xxx == 2 to dopisujemy dodatkowa treść do oryginału przez block append

Jak to rozwiązać ?? kombinowałem z : {if warunekdospelnienia} {block name=xxx} zawartosc nowego blooku {/block} {else} {block name=xxx append} zawartosc nowego bloku {/block} {/if}

a nie lepiej ten warunek rozwiązać w php i przekazać wynik do smarty?

A w jaki sposób ten warunek rozwiązać w pluginie gdzie wynik ma skutkować tylko i wyłącznie zmianą wyświetlania danego bloku ? Tak naprawdę to chodzi o magiczną opcję "append" dodawaną do interesującego mnie bloku. Składnia w przykładzie (z tym, że append był w spełnionym warunku czyli u góry) dawała w wyniku 2x zawartość nowego bloku niezależnie od tego czy if był spełniony czy nie. Może sposobem na takie cuś byłaby sekcja ({section}) ?

---

lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms

---

lms mailing listlms@lists.lms.org.plhttp://lists.lms.org.pl/mailman/listinfo/lms

-- Pozdrawiam Michał Szmigielski /ernesttar/

---

lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms

Ernest bardzi Ci dziękuję. Teraz zaczęło działać.

W dniu 9 listopada 2015 11:09 użytkownik Ernest ernest@poczta.tarman.pl napisał:

Witam.

@Marcin Już sobie poradziłem ;) w najprostszy możliwy sposób. Zastapilem oryginalny blok 3 wersjami nowego na if,elseif,else (ma to obecnie niestety ten minus, ze jezeli zmieni sie oryginalny szablon /na ktory mam maly wplyw/ to zmiany nie beda uwzgledniane) chyba jeszcze się pobawię z {capture};) ...

...

....tu trzeba pomyśleć, co konkretnie robisz i jaki chcesz mieć efekt? bo

cały czas piszesz o .html, ale nie wiemy z jakiego poziomu to wywołujesz.

Na tym etapie nie "dotykam" w żadnym miejscu modułów, po prostu chcę zmienić sposób prezentacji danych co powinno dać się zrobić samymi szablonami. SMARTY jak każdy system szablonów ma swoje "plusy dodatnie i plusy ujemne" ;) po prostu pewne rzeczy robi się intuicyjnie a nad pewnymi trzeba się "pokiwać".

@loleo2

...

Włączyłem, klikając na żarówkę z poziomu wtyczek. A czy zawartość pliku którą przedstawiłem jest ok? Bo ja nie bardzo

rozumiem dlaczego extends robimy >pliku layout.html a nie welcome.html, Jak najbardziej możesz extends robić dla pliku welcome.html Możesz nawet wybrać, który blok z oryginalnego pliku chcesz modyfikować(zastąpić, dopisać przed, dopisać po).

...

po za tym jakie ma znaczenie nazwa pliku w templates oraz jesgo umiejscowienie w strukturze katalogów, tzn. przykładowo welcome.html

normlanie jest w >templates/default/welcome/ a tutaj włożony jest do /templates/welcome. Co do umiejscowienia nowego pliku to w zasadzie nie jest (chyba) ważne byle był w katalogu templates w pluginie.

...

Nie wiem np. czy może nie trzeba kasować zakeszowanego pliku w

templates_c żeby to się odświerzyło?

...

Jeśli zadaję pytania na kóre gdzieś jest już podpowedź to proszę o

jakiegoś linka, bo ja jakoś nie trafiłem Nie jest to konieczne. Za to konieczne jest dopisanie do pluginu funkcji dodającej katalog templates z pluginu do ścieżki wyszukiwania szablonów czego w przykładowym nie ma: Kod made by Jarosław Dziubek ;)

fragment pliku "ExamplePlugin.php": class PluginExample extends LMSPlugin { //(...) public function registerHandlers() { $this->handlers = array( 'smarty_initialized' => array( 'class' => 'WelcomeHandler', 'method' => 'smartyInit' ), //(...)

fragment pliku "handlers/WelcomeHandler.php": class PluginExample { /** * Sets plugin Smarty templates directory * * @param Smarty $hook_data Hook data * @return \Smarty Hook data */ public function smartyInit(Smarty $hook_data) { $template_dirs = $hook_data->getTemplateDir(); $plugin_templates = PLUGINS_DIR . '/ExamplePlugin/templates'; array_unshift($template_dirs, $plugin_templates); $hook_data->setTemplateDir($template_dirs); return $hook_data; } //(......)

Oczywiście przejrzyściej byłoby wrzucić toto do osobnej klasy "inicjalizacja_pluginu_xxx"

plik "templates/welcome/welcome.html ": {extends file="welcome/welcome.html"} {block name=welcome-right-panel} testowa modyfikacja {/block}

Pozdrawiam /ernesttar/

W dniu 11/09/2015 o 10:13 AM, Ernest pisze:

Witaj Marcinie.(skoro nie lubisz wykrzykników to kropka ;) )

Ja się nie upieram żeby zrobić to w smarty. Jest zdefiniowany szablon z blokiem i teraz w zależności od zawartości phpui potrzebuję wyświetlić albo oryginalny blok, albo nowy, albo obydwa. Jeśli jest sposób żeby zrobić to z poziomu plugina to proszę o podpowiedz.

Po weekendowej przerwie przychodzi mi jeszcze do głowy pomysł (oparty jednak na smarty) z funkcją {capture} (gdzies na listach coś takiego wyszukałem)

Pozdrawiam /ernesttar/ W dniu 11/06/2015 o 05:15 PM, Marcin pisze:

Możesz też przygotować dwa pliki html i w zależności od warunku w php wyświetlać odpowiedni plik. 6 lis 2015 16:05 "Ernest" ernest@poczta.tarman.pl napisał(a):

...

W dniu 11/06/2015 o 03:51 PM, Marcin pisze:

W dniu 6 listopada 2015 15:37 użytkownik Ernest ernest@poczta.tarman.pl napisał:

...

W dniu 11/06/2015 o 02:45 PM, Marcin pisze:

W dniu 6 listopada 2015 14:37 użytkownik Ernest <ernest@poczta.tarman.pl

...

napisał:

...

W dniu 11/06/2015 o 02:07 PM, Marcin pisze:

...

Dodałem kilka regionów z blokami puściłem pull requesta, jak Tomek

zaakceptuje to może starczy.

Nie chodzi tu o to, żeby ktoś specjalnie siedział nad szablonami i je poprawiał.

Aczkolwiek racja. netdevinfo był bezblokowy, więc co za problem na przyszłość ułatwić innym życie?

...

Teraz mam już gotowe, tylko że zrobione zgodnie ze wzorem na samym dole. Sam mogę zrobić pull request ;)

To czemu nie robisz?

Poszły 2 szt. reszta jak skończę przepisywać wtyczkę ;)

Mam jeszcze pytanko. Chciałbym uzależnić sposób wyświetlania danego bloku od zawartości config.phpui w takim sensie, że np. jeżeli phpui.xxx == 1 to zamieniam blok jeżeli phpui.xxx == 2 to dopisujemy dodatkowa treść do oryginału przez block append

Jak to rozwiązać ?? kombinowałem z : {if warunekdospelnienia} {block name=xxx} zawartosc nowego blooku {/block} {else} {block name=xxx append} zawartosc nowego bloku {/block} {/if}

a nie lepiej ten warunek rozwiązać w php i przekazać wynik do smarty?

A w jaki sposób ten warunek rozwiązać w pluginie gdzie wynik ma skutkować tylko i wyłącznie zmianą wyświetlania danego bloku ? Tak naprawdę to chodzi o magiczną opcję "append" dodawaną do interesującego mnie bloku. Składnia w przykładzie (z tym, że append był w spełnionym warunku czyli u góry) dawała w wyniku 2x zawartość nowego bloku niezależnie od tego czy if był spełniony czy nie. Może sposobem na takie cuś byłaby sekcja ({section}) ?

---

lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms

---

lms mailing listlms@lists.lms.org.plhttp://lists.lms.org.pl/mailman/listinfo/lms

-- Pozdrawiam Michał Szmigielski /ernesttar/

---

lms mailing listlms@lists.lms.org.plhttp://lists.lms.org.pl/mailman/listinfo/lms

-- Pozdrawiam Michał Szmigielski /ernesttar/

---

lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms

W dniu 10.11.2015 08:29, Ernest napisał(a):

Witam.

Witam,

@Chilan Dałoby się wcisnąć "rejestrację" katalogów szablonów wtyczek gdzieś z automatu, tak żeby nie trzeba było w każdej wtyczce osobno ich dodawać?

Nie każdy plugin tego potrzebuje, a dodawanie na stałe sprawdzania katalogów dla każdego aktywnego pluginu może spowodować spowolenienie pracy LMS-a. Spróbuję zrobić tak, żeby przynajmniej to było prostsze niż obecnie, np. przez wywołanie pojedynczej metody z klasy LMSPlugin.

Pozdrawiam Michał Szmigielski /ernesttar/

W dniu 11/10/2015 o 01:27 AM, loleo2 pisze:

...

Ernest bardzi Ci dziękuję. Teraz zaczęło działać.

W dniu 9 listopada 2015 11:09 użytkownik Ernest ernest@poczta.tarman.pl napisał:

...

Witam.

@loleo2

...

Włączyłem, klikając na żarówkę z poziomu wtyczek. A czy zawartość pliku którą przedstawiłem jest ok? Bo ja nie

bardzo rozumiem dlaczego extends robimy >pliku layout.html a nie welcome.html, Jak najbardziej możesz extends robić dla pliku welcome.html Możesz nawet wybrać, który blok z oryginalnego pliku chcesz modyfikować(zastąpić, dopisać przed, dopisać po).

...

po za tym jakie ma znaczenie nazwa pliku w templates oraz jesgo umiejscowienie w strukturze katalogów, tzn. przykładowo

welcome.html normlanie jest w >templates/default/welcome/ a tutaj włożony jest do /templates/welcome. Co do umiejscowienia nowego pliku to w zasadzie nie jest (chyba) ważne byle był w katalogu templates w pluginie.

...

Nie wiem np. czy może nie trzeba kasować zakeszowanego pliku w

templates_c żeby to się odświerzyło?

...

Jeśli zadaję pytania na kóre gdzieś jest już podpowedź to

proszę o jakiegoś linka, bo ja jakoś nie trafiłem Nie jest to konieczne. Za to konieczne jest dopisanie do pluginu funkcji dodającej katalog templates z pluginu do ścieżki wyszukiwania szablonów czego w przykładowym nie ma: Kod made by Jarosław Dziubek ;)

fragment pliku "ExamplePlugin.php": class PluginExample extends LMSPlugin { //(...) public function registerHandlers() { $this->handlers = array( 'smarty_initialized' => array( 'class' => 'WelcomeHandler', 'method' => 'smartyInit' ), //(...)

fragment pliku "handlers/WelcomeHandler.php": class PluginExample { /**

• Sets plugin Smarty templates directory
• @param Smarty $hook_data Hook data
• @return \Smarty Hook data

*/ public function smartyInit(Smarty $hook_data) { $template_dirs = $hook_data->getTemplateDir(); $plugin_templates = PLUGINS_DIR . '/ExamplePlugin/templates'; array_unshift($template_dirs, $plugin_templates); $hook_data->setTemplateDir($template_dirs); return $hook_data; } //(......)

Oczywiście przejrzyściej byłoby wrzucić toto do osobnej klasy "inicjalizacja_pluginu_xxx"

plik "templates/welcome/welcome.html ": {extends file="welcome/welcome.html"} {block name=welcome-right-panel} testowa modyfikacja {/block}

Pozdrawiam /ernesttar/

---

lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms

W dniu 10.11.2015 09:05, Marcin napisał(a):

Witam

Witam,

Jak bym bardziej poprosił o zrobienie paginacji dla list klientów, komputerów finansów itp. Obecnie jak klikamy listę klientów z bazy pobierane są wszytkie rekordy a później paginowane, skutkuje to przesłaniem do smarty całości zawartości "bazy". Przy kilkuset klientach nie ma to bardzo dużego znaczenia ale jak suma wpisów jest w tysiącach a historia operacji w setkach tysięcy robi się już mało wydajnie. Moim zdaniem można by pobrać ilość rekordów, przeliczyć ile stron paginaci i pobrać odpowiedni limit z wyliczonym offsetem z bazy. będzie znacznie wydajniej i szybciej.

Podeślesz odpowiedniego pull requesta?

W dniu 10 listopada 2015 08:45 użytkownik Tomasz Chiliński tomasz.chilinski@chilan.com napisał:

...

W dniu 10.11.2015 08:29, Ernest napisał(a):

...

Witam.

Witam,

...

@Chilan Dałoby się wcisnąć "rejestrację" katalogów szablonów wtyczek gdzieś z automatu, tak żeby nie trzeba było w każdej wtyczce osobno ich dodawać?

Nie każdy plugin tego potrzebuje, a dodawanie na stałe sprawdzania katalogów dla każdego aktywnego pluginu może spowodować spowolenienie pracy LMS-a. Spróbuję zrobić tak, żeby przynajmniej to było prostsze niż obecnie, np. przez wywołanie pojedynczej metody z klasy LMSPlugin.

Pozdrawiam Michał Szmigielski /ernesttar/

W dniu 11/10/2015 o 01:27 AM, loleo2 pisze:

Ernest bardzi Ci dziękuję. Teraz zaczęło działać.

W dniu 9 listopada 2015 11:09 użytkownik Ernest ernest@poczta.tarman.pl napisał:

Witam.

@loleo2 Włączyłem, klikając na żarówkę z poziomu wtyczek. A czy zawartość pliku którą przedstawiłem jest ok? Bo ja nie bardzo rozumiem dlaczego extends robimy >pliku layout.html a nie welcome.html, Jak najbardziej możesz extends robić dla pliku welcome.html Możesz nawet wybrać, który blok z oryginalnego pliku chcesz modyfikować(zastąpić, dopisać przed, dopisać po).

po za tym jakie ma znaczenie nazwa pliku w templates oraz jesgo umiejscowienie w strukturze katalogów, tzn. przykładowo welcome.html normlanie jest w >templates/default/welcome/ a tutaj włożony jest do /templates/welcome. Co do umiejscowienia nowego pliku to w zasadzie nie jest (chyba) ważne byle był w katalogu templates w pluginie.

Nie wiem np. czy może nie trzeba kasować zakeszowanego pliku w templates_c żeby to się odświerzyło? Jeśli zadaję pytania na kóre gdzieś jest już podpowedź to proszę o jakiegoś linka, bo ja jakoś nie trafiłem Nie jest to konieczne. Za to konieczne jest dopisanie do pluginu funkcji dodającej katalog templates z pluginu do ścieżki wyszukiwania szablonów czego w przykładowym nie ma: Kod made by Jarosław Dziubek ;)

fragment pliku "ExamplePlugin.php": class PluginExample extends LMSPlugin { //(...) public function registerHandlers() { $this->handlers = array( 'smarty_initialized' => array( 'class' => 'WelcomeHandler', 'method' => 'smartyInit' ), //(...)

fragment pliku "handlers/WelcomeHandler.php": class PluginExample { /**

• Sets plugin Smarty templates directory
• @param Smarty $hook_data Hook data
• @return \Smarty Hook data

*/ public function smartyInit(Smarty $hook_data) { $template_dirs = $hook_data->getTemplateDir(); $plugin_templates = PLUGINS_DIR . '/ExamplePlugin/templates'; array_unshift($template_dirs, $plugin_templates); $hook_data->setTemplateDir($template_dirs); return $hook_data; } //(......)

Oczywiście przejrzyściej byłoby wrzucić toto do osobnej klasy "inicjalizacja_pluginu_xxx"

plik "templates/welcome/welcome.html ": {extends file="welcome/welcome.html"} {block name=welcome-right-panel} testowa modyfikacja {/block}

Pozdrawiam /ernesttar/

---

lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms

-- Pozdrawiam Tomasz Chiliński, Chilan

---

lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms

--

Pozdrawiam Marcin / nicraM

W dniu 10 listopada 2015 11:53 użytkownik Maciej Lew < maciej.lew.1987@gmail.com> napisał:

Mam przygotowaną lepszą paginację, postaram się przygotować pulla.

Ok, bo już brałem się za pisanie

10-11-2015 09:08, "Tomasz Chiliński" tomasz.chilinski@chilan.com napisał(a):

...

W dniu 10.11.2015 09:05, Marcin napisał(a):

...

Witam

Witam,

Jak bym bardziej poprosił o zrobienie paginacji dla list klientów,

...

komputerów finansów itp. Obecnie jak klikamy listę klientów z bazy pobierane są wszytkie rekordy a później paginowane, skutkuje to przesłaniem do smarty całości zawartości "bazy". Przy kilkuset klientach nie ma to bardzo dużego znaczenia ale jak suma wpisów jest w tysiącach a historia operacji w setkach tysięcy robi się już mało wydajnie. Moim zdaniem można by pobrać ilość rekordów, przeliczyć ile stron paginaci i pobrać odpowiedni limit z wyliczonym offsetem z bazy. będzie znacznie wydajniej i szybciej.

Podeślesz odpowiedniego pull requesta?

W dniu 10 listopada 2015 08:45 użytkownik Tomasz Chiliński

...

tomasz.chilinski@chilan.com napisał:

W dniu 10.11.2015 08:29, Ernest napisał(a):

...

Witam.

...

Witam,

@Chilan

...

Dałoby się wcisnąć "rejestrację" katalogów szablonów wtyczek gdzieś z automatu, tak żeby nie trzeba było w każdej wtyczce osobno ich dodawać?

Nie każdy plugin tego potrzebuje, a dodawanie na stałe sprawdzania katalogów dla każdego aktywnego pluginu może spowodować spowolenienie pracy LMS-a. Spróbuję zrobić tak, żeby przynajmniej to było prostsze niż obecnie, np. przez wywołanie pojedynczej metody z klasy LMSPlugin.

Pozdrawiam Michał Szmigielski /ernesttar/

W dniu 11/10/2015 o 01:27 AM, loleo2 pisze:

Ernest bardzi Ci dziękuję. Teraz zaczęło działać.

W dniu 9 listopada 2015 11:09 użytkownik Ernest ernest@poczta.tarman.pl napisał:

Witam.

@loleo2 Włączyłem, klikając na żarówkę z poziomu wtyczek. A czy zawartość pliku którą przedstawiłem jest ok? Bo ja nie bardzo rozumiem dlaczego extends robimy >pliku layout.html a nie welcome.html, Jak najbardziej możesz extends robić dla pliku welcome.html Możesz nawet wybrać, który blok z oryginalnego pliku chcesz modyfikować(zastąpić, dopisać przed, dopisać po).

po za tym jakie ma znaczenie nazwa pliku w templates oraz jesgo umiejscowienie w strukturze katalogów, tzn. przykładowo welcome.html normlanie jest w >templates/default/welcome/ a tutaj włożony jest do /templates/welcome. Co do umiejscowienia nowego pliku to w zasadzie nie jest (chyba) ważne byle był w katalogu templates w pluginie.

Nie wiem np. czy może nie trzeba kasować zakeszowanego pliku w templates_c żeby to się odświerzyło? Jeśli zadaję pytania na kóre gdzieś jest już podpowedź to proszę o jakiegoś linka, bo ja jakoś nie trafiłem Nie jest to konieczne. Za to konieczne jest dopisanie do pluginu funkcji dodającej katalog templates z pluginu do ścieżki wyszukiwania szablonów czego w przykładowym nie ma: Kod made by Jarosław Dziubek ;)

fragment pliku "ExamplePlugin.php": class PluginExample extends LMSPlugin { //(...) public function registerHandlers() { $this->handlers = array( 'smarty_initialized' => array( 'class' => 'WelcomeHandler', 'method' => 'smartyInit' ), //(...)

fragment pliku "handlers/WelcomeHandler.php": class PluginExample { /**

• Sets plugin Smarty templates directory
• @param Smarty $hook_data Hook data
• @return \Smarty Hook data

*/ public function smartyInit(Smarty $hook_data) { $template_dirs = $hook_data->getTemplateDir(); $plugin_templates = PLUGINS_DIR . '/ExamplePlugin/templates'; array_unshift($template_dirs, $plugin_templates); $hook_data->setTemplateDir($template_dirs); return $hook_data; } //(......)

Oczywiście przejrzyściej byłoby wrzucić toto do osobnej klasy "inicjalizacja_pluginu_xxx"

plik "templates/welcome/welcome.html ": {extends file="welcome/welcome.html"} {block name=welcome-right-panel} testowa modyfikacja {/block}

Pozdrawiam /ernesttar/

---

lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms

-- Pozdrawiam Tomasz Chiliński, Chilan

---

lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms

--

Pozdrawiam Marcin / nicraM

-- Pozdrawiam Tomasz Chiliński, Chilan _______________________________________________ lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms

---

lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms

W dniu 06.11.2015 13:39, Ernest napisał(a):

Witam !!!

Witam,

Panie Tomku mam następujące pytanie/propozycję:

Czy w module pluginlist, na liscie dostępnych pluginów dałoby się umieścić przycisk Install/Uninstall i skorelowane z nim hook`i ?

Aktualnie jeżeli plugin nie korzysta ze swoich własnych tabel to w zasadzie wystarczy skopiować go do katalogu z pluginami i włączyć, jeżeli natomiast dochodzą to tego tabele własne wtyczki to przy każdym uruchomieniu trzeba sprawdzać czy wymagane tabele są utworzone i zapewnić korelacje z pozostałymi tabelami.

Akcja install pozwalałaby takie coś przeprowadzić tylko raz na specjalne życzenie. Uninstall podobnie. Chyba, że takowy hook dostępny jest w momencie włączania(aktywacji) pluginu.

Nie do końca jest tak, że sprawdzana jest obecność dodatkowych tabel dla wtyczki. W rzeczywistości następuje sprawdzenie obecności rekordu w dbinfo z keytype dbversion_PluginName i: 1) Jeśli w ogóle nie ma takiego rekordu następuje ładowanie pliku doc/lms.{pgsql,mysql} z katalogu z pluginem. 2) Jeśli jest taki rekord, ale ma datę starszą niż pliki z aktualizacjami schematu pluginu to następuje załadowanie tych plików aktualizacji.

W związku z powyższym - nie da się załatwić załadowania schematu i potem jego uaktualniania w ramach pluginu akcjami install i uninstall.

Pozostaje w takim wypadku jeszcze ewentualne odinstalowanie wtyczki (skasowanie dodatkowych tabel).

Nie wiem czy to byłoby pożądane zachowanie, gdyby akcja uninstall powodowała skasowanie danych w bazie danych używanych przez wtyczkę. Chyba przy takim podejściu lepiej byłoby mieć akcje install/uninstall i enable/disable (właśnie tak jest w cacti). Wtedy wyłączenie pluginu nie powoduje skasowania danych w bazie danych.

Dodatkowo, oczywiście jeśli pan Tomek nie będzie miał nic przeciwko temu, prośba do wszystkich, którzy piszą własne wtyczki o wzbogacenie oryginalnych plików szablonów (oczywiście tych których dotyczy wtyczka no chyba, że już będą zrobione to wtedy jakikolwiek inny) o bloki ( na wzór vioipaccounts ) i wysłanie ich jako commit`a na git. Myślę, że taka akcja bardzo ułatwi życie nam wszystkim przy pisaniu kolejnych wtyczek.

Osobiście widzę to tak, że dzielimy szablon na jak najmniejsze bloki (nazwapliku-wyróżnik_bloku), dzięki którym wtyczki maja punkt zaczepienia dla swoich danych i nie trzeba rozszerzać głównego pliku tylko fragment o który nam chodzi przez co zmniejsza się niebezpieczeństwo konfliktu pomiędzy wtyczkami. Poniżej przykładowy fragment.

Pozdrawiam Michał Szmigielski /ernesttar/

(fragment pliku "netdev/netdevinfobox.html" wzbogacony o bloki) ..... {if $netdevinfo.model} {block name="netdevinfobox-model"}<!-- dodatkowy znacznik bloku --> <TR> <TD WIDTH="1%"> <IMG SRC="img/netdev_model.gif" ALT=""> </TD> <TD WIDTH="1%"> <B>{trans("Model:")}</B> </TD> <TD WIDTH="98%"> {$netdevinfo.model} </TD> </TR> {/block} {/if} {if $netdevinfo.serialnumber} {block name="netdevinfobox-serial"} <!-- dodatkowy znacznik bloku --> <TR> <TD WIDTH="1%"> <IMG SRC="img/serialnumber.gif" ALT=""> </TD> <TD WIDTH="1%" NOWRAP> <B>{trans("Serial number:")}</B> </TD> <TD WIDTH="98%"> {$netdevinfo.serialnumber} </TD> </TR> {/block} {/if} ...

W dniu 10/08/2015 o 08:15 PM, Tomasz Chiliński pisze:

...

W dniu 08.10.2015 19:37, Maciej Lew napisał(a):

...

Co masz przez to na myśli? Odebranie danych z jakiegoś managera i wciśnięcie ich w pętlę hooków? Czy coś innego?

Mniej więcej tak.

---

lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms

Dodałem kilka regionów z blokami puściłem pull requesta, jak Tomek zaakceptuje to może starczy

W dniu 6 listopada 2015 13:39 użytkownik Ernest ernest@poczta.tarman.pl napisał:

Witam !!!

Panie Tomku mam następujące pytanie/propozycję:

Czy w module pluginlist, na liscie dostępnych pluginów dałoby się umieścić przycisk Install/Uninstall i skorelowane z nim hook`i ?

Aktualnie jeżeli plugin nie korzysta ze swoich własnych tabel to w zasadzie wystarczy skopiować go do katalogu z pluginami i włączyć, jeżeli natomiast dochodzą to tego tabele własne wtyczki to przy każdym uruchomieniu trzeba sprawdzać czy wymagane tabele są utworzone i zapewnić korelacje z pozostałymi tabelami.

Akcja install pozwalałaby takie coś przeprowadzić tylko raz na specjalne życzenie. Uninstall podobnie. Chyba, że takowy hook dostępny jest w momencie włączania(aktywacji) pluginu.

Pozostaje w takim wypadku jeszcze ewentualne odinstalowanie wtyczki (skasowanie dodatkowych tabel).

Dodatkowo, oczywiście jeśli pan Tomek nie będzie miał nic przeciwko temu, prośba do wszystkich, którzy piszą własne wtyczki o wzbogacenie oryginalnych plików szablonów (oczywiście tych których dotyczy wtyczka no chyba, że już będą zrobione to wtedy jakikolwiek inny) o bloki ( na wzór vioipaccounts ) i wysłanie ich jako commit`a na git. Myślę, że taka akcja bardzo ułatwi życie nam wszystkim przy pisaniu kolejnych wtyczek.

Osobiście widzę to tak, że dzielimy szablon na jak najmniejsze bloki (nazwapliku-wyróżnik_bloku), dzięki którym wtyczki maja punkt zaczepienia dla swoich danych i nie trzeba rozszerzać głównego pliku tylko fragment o który nam chodzi przez co zmniejsza się niebezpieczeństwo konfliktu pomiędzy wtyczkami. Poniżej przykładowy fragment.

Pozdrawiam Michał Szmigielski /ernesttar/

(fragment pliku "netdev/netdevinfobox.html" wzbogacony o bloki) ..... {if $netdevinfo.model} {block name="netdevinfobox-model"}<!-- dodatkowy znacznik bloku --> <TR> <TD WIDTH="1%"> <IMG SRC="img/netdev_model.gif" ALT=""> </TD> <TD WIDTH="1%"> <B>{trans("Model:")}</B> </TD> <TD WIDTH="98%"> {$netdevinfo.model} </TD> </TR> {/block} {/if} {if $netdevinfo.serialnumber} {block name="netdevinfobox-serial"} <!-- dodatkowy znacznik bloku --> <TR> <TD WIDTH="1%"> <IMG SRC="img/serialnumber.gif" ALT=""> </TD> <TD WIDTH="1%" NOWRAP> <B>{trans("Serial number:")}</B> </TD> <TD WIDTH="98%"> {$netdevinfo.serialnumber} </TD> </TR> {/block} {/if} ...

W dniu 10/08/2015 o 08:15 PM, Tomasz Chiliński pisze:

...

W dniu 08.10.2015 19:37, Maciej Lew napisał(a):

...

Co masz przez to na myśli? Odebranie danych z jakiegoś managera i wciśnięcie ich w pętlę hooków? Czy coś innego?

Mniej więcej tak.

---

lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms

Smarty include, extend 13 paź 2015 11:46 "Ernest" ernest@poczta.tarman.pl napisał(a):

Witam !!!

Myślę, że podejście Chillan`a jest bardziej "user-friendly" ;) za to mam pytanie. W jaki sposób radzicie sobie z nakładaniem szablonów na siebie? Chodzi o to, że powiedzmy mamy 2 różne pluginy, które modyfikują ten sam zestaw szablonów.

W dniu 10/08/2015 o 07:37 PM, Maciej Lew pisze:

...

Co masz przez to na myśli? Odebranie danych z jakiegoś managera i wciśnięcie ich w pętlę hooków? Czy coś innego?

W dniu 08.10.2015 o 19:16, Tomasz Chiliński pisze:

...

W dniu 08.10.2015 19:11, Maciej Lew napisał(a):

...

Nie widzę uniwersalnego rozwiązania takiego problemu. Można by mechanizmami refleksji spróbować z wnętrza pluginu sprawdzić czy inny plugin już przesłonił domyślnego managera którego również aktualny plugin chce przesłonić i w jakiś sposób ostrzec użytkownika przed konfliktem.

W praktyce okazuje się, że najlepiej realizować kaskadowe zmiany w manager-ach nie przez tworzenie potomnego managera, a kaskadowe/potokowe przetwarzanie wyników.

W dniu 08.10.2015 o 19:03, Tomasz Chiliński pisze:

...

...

W dniu 08.10.2015 18:44, Maciej Lew napisał(a):

...

Mówiąc o innych sposobach miałem na myśli wstrzykiwanie zależności w LMS. W tym celu LMS został w większości przerobiony na fasadę dla "managerów". W klasie LMS są specjalne metody pozwalające zastąpić domyślnych managerów własnymi.

Cześć,

w jaki sposób rozwiązujesz kaskadowe (łańcuchowe) tworzenie managerów tak, żeby np. z wielu wtyczek jednocześnie móc modyfikować tego samego managera?

W dniu 08.10.2015 o 12:50, Ernest pisze:

...

Witam !!! > Panie Maćku, > dzięki za wyjaśnienie i pomoc! > > Zastanawiam się czy nie można w jakiś sposób dodać > "automagicznie" ;) hook`ow przynajmniej przed wyświetleniem danego > szablonu? > Takie cuś załatwiłoby praktycznie wszystkie pluginy dodające > coś do wyświetlanej treści. > > Druga sprawa to nadpisywanie szablonów. > Jeżeli "poprawiamy" dany blok w którym są includy innych plików > np. > <************************* > {extends file="layout.html"} > {block name=title}::: LMS :{$layout.pagetitle|striphtml} :::{/block} > {block name=module_content} > <!--// $Id$ //--> > {$xajax} > <H1>{$layout.pagetitle}</H1> > <TABLE style="width: 100%;"> > <TR> > <TD style="width: 100%;"> > {include file="netdev/netdevinfobox.html"} {*-----ten > plik występuje w oryginalnych szablonach i w pluginie----*} > ..... > <***************************** > > i załączany plik ma taką samą nazwę jak istniejący to smarty > wyświetla plik oryginalny > (taki przynajmniej przypadek był u mnie i jak przypuszczam u kolegi > Jarosława /plugin do mikrotika/) > W jaki sposób można się przed takim problemem uchronić (poza > zmianą nazwy pliku załączanego) ?? > > Co do innej drogi wykonania zadania to chyba właśnie po to trwają > prace nad systemem wtyczek żeby nie trzeba było gmerać w kodzie > silnika. > > Funkcjonalność która się właśnie przepisuje trochę zmienia > podejście do połączeń pomiędzy urządzeniami. > Zamiast(albo obok) zapisywania linków ptp bez wyraźnie > określonego kierunku dodaję tabelę, w której zapisywane są > relacje w stylu wiele do jednego (czyli np switch5 ma port UPLINK(nr > np. 1) i łączy się ze switchem3 (na port 5), > > przykładowa tabela: netdevid,uplinkport,dstnetdevid,dstport....(tu > oczywiście dane linku: typ,prędkość) > > pozwala to stworzyć wyraźne drzewo(ścieżkę) połączeń od > urządzeń końcowych aż do głównego routera sieci. > Czyli będąc na jakimkolwiek urządzeniu jestem w stanie > jednoznacznie określić na jakim porcie otrzymuje ono sygnał a na > jakich przesyła go dalej. > Dodatkowo od najwcześniejszych wersji LMS`a denerwowało mnie > "ręczne"(właściwie to pamięciowe) określanie numerów portów w > połączeniach dlatego dopisuję do wtyczki okienko ajaxowe na > zasadzie wybierania adresu IP. > > Jak skończę to jeśli będą chętni podzielę się wynikami ;) > > Uff ale się rozpisałem ;) > > Pozdrawiam > Michal Szmigielski > /ernesttar/ > > W dniu 10/06/2015 o 07:14 PM, Maciej Lew pisze: > Przeszukaj sobie projekt pod kątem występowania metod > "executeHook". Nie są one jeszcze dodane w każdym module, raczej > zostały dodane tam gdzie komuś opłacało się je dodać. > Przejrzenie wszystkich modułów i dodanie hooków to strasznie > dużo roboty i raczej nikt tego nie zrobi tylko po to żeby były i > czekały aż komuś staną się przydatne. Jeśli potrzebujesz > gdzieś hooka gdzie go nie ma to myślę że jak przygotujesz > odpowiedniego commita do głównej gałęzi to zostanie on > przyjęty. > > Istnieje także możliwość że to samo zadanie da się zrobić w > inny sposób, bez dodawania hooka. Ale musiałbyś bardziej opisać > co chcesz osiągnąć. > > W dniu 06.10.2015 o 16:05, Marcin pisze: > > Nazwy uchwytów masz w kodzie są różne w zależności od miejsca > 6 paź 2015 16:02 "Ernest" ernest@poczta.tarman.pl napisał(a): > > Witam !!! > > Próbuję właśnie poprzepisywać swoje "dodatki" na pluginy. > Jako, że programista ze mnie dość marny mam pytanie. > W jaki sposób definiować "uchwyty" (Handlers)? > > Z tego co zrozumiałem, to w poszczególnych modułach są > umieszczone wpisy typu > "$LMS->executeHook('useradd_validation_before_submit', > array('useradd' => $useradd,...." > czyli uchwyty są zdefiniowane w silniku skryptu. > > Zatem wygląda na to, że jest ich trochę mało. > > Dodam, że system "wtyczkowy" szalenie mi się podoba z tego > względu, że nie ingeruje bezpośrednio w kod silnika co jest > dość problematyczne (co użytkownik to inne potrzeby więc i inne > modyfikacje kodu/bazy danych). > > Pozdrawiam > Michal Szmigielski > /ernesttar/ > _______________________________________________ > lms mailing list > lms@lists.lms.org.pl > http://lists.lms.org.pl/mailman/listinfo/lms > > _______________________________________________ > lms mailing list > lms@lists.lms.org.pl > http://lists.lms.org.pl/mailman/listinfo/lms >

-- lion.net.pl - wdrożenia i rozwój Lan Management System

---

lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms

---

lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms

-- lion.net.pl - wdrożenia i rozwój Lan Management System

---

lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms

---

lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms