![]() |
![]() |
![]()
Post
#1
|
|
Grupa: Zarejestrowani Postów: 111 Pomógł: 1 Dołączył: 24.12.2013 Ostrzeżenie: (0%) ![]() ![]() |
Czesc wszystkim
Chcialbym stworzyc pasek narzedzi, ktory wyswietlalby sie na okreslonych stronach. Mialby mozliwosc dodawania w nim tabow, a w tych zakladkach przyciskow, pod ktore bylyby podlaczone okreslone akcje. Chcialbym takze dac mozliwosc dodatkom rejestrowania swoich kart i przyciskow. Dzieki temu, na takim pasku mozna byloby znalezc chociazby przycisk do edycji artykulu, jezeli dana podstrona bylaby wlasnie zaladowana. Zastanawiam sie jak to rozwiazac. Z jednej strony wyobrazam sobie, ze najpierw tworzylbym pasek i z niego tworzyl karte:
Nastepnie na jednej z takich zakladek moglbym dodawac przyciski i separatory:
Zapis wydaje sie byc czytelny i zrozumialy. A moze jednak, powinienem uznac ze kazdy element takiego toolbara jest obiektem i podejsc do problemu od 2 strony, tj najpierw stworzyc, przyciski, pozniej umiescic je na tabie, ktory ostatecznie zaalokowac na pasku narzedzi?
Ktora opcja jest wg Was lepsza i dlaczego? A moze polecicie jeszcze inne rozwiazanie? Docelowo, chcialbym aby na pasku narzedzi mogly znalezc sie tylko zakladki, a na kazdej zakladce mogly byc umieszczone: * przyciski, * listy rozwijane * przyciski z rozwijanymi menu |
|
|
![]() |
![]()
Post
#2
|
|
Grupa: Zarejestrowani Postów: 516 Pomógł: 63 Dołączył: 27.08.2012 Ostrzeżenie: (0%) ![]() ![]() |
dlaczego w ogóle budujesz elementy szablonu w phpie ? Wg mnie to bez sensu. Akce możesz przeciez elegancko obsłużyć w javascript/ajax a po stronie php'a zostanie tylko obsługa żądań. Zapis zmian wrzucasz do bazy i je wyciągasz wg twoich założeń
Ten post edytował gitbejbe 23.03.2016, 21:28:46 |
|
|
![]()
Post
#3
|
|
Grupa: Zarejestrowani Postów: 111 Pomógł: 1 Dołączył: 24.12.2013 Ostrzeżenie: (0%) ![]() ![]() |
No tak, ale jak dorzucisz do systemu jakis dodatek i bedzie on zaladowany podczas wyswietlania danej podstrony, to on musi zarejestrowac na tym toolbarze, swoje przyciski, ew. calego taba.
Wiec chcialem dac taka mozliwosc po stronie PHP, a pozniej odpowiednio wygenerowac widok. |
|
|
![]()
Post
#4
|
|
Grupa: Zarejestrowani Postów: 516 Pomógł: 63 Dołączył: 27.08.2012 Ostrzeżenie: (0%) ![]() ![]() |
to przede wszystkim zastanów się na podstawie czego będzie go generował. Jeśli użytkownik sobie skonfiguruje jakieś tam przyciski, to rozumiem, że będzie miał możliwość zapisania tej konfiguracji. Skoro pojawia się zapis, to siłą rzeczy musisz wrzucić do bazy tą konfiguracje. Zrobisz to zapewne w ten sposób , że użytkownik o ID jakiś tam, ma np
jeśli użytkownik ponownie wejdzie na stronę, na której powinien zobaczyć swoją konfiguracje, to wybierasz z bazy zapis, w php'ie go obrabiasz dla widoku i tyle. Tak więc Twoja klasę - jeśli uważasz ją za konieczną, napisałbym w kierunku obróbki dla gotowego zestawu danych. Wrzucasz całą konfiguracje przy tworzeniu obiektu, a klasa sama wszystko obrabia wg Twoich założeń i zwraca Ci gotowe dane dla widoku, które wyświetlisz sobie gdzie i jak chcesz. Proponuje rozbić klasę na abstrakcyjną - główną, oraz klasy po niej dziedziczące - czyli wszystkie elementy, które toolbar będzie posiadał. Klasa główna będzie rozpoznawać po wprowadzonych danych, jakie klasy dziedziczące wywołać. W ten sposób łatwo będziesz mógł dodawać nowe elementy jak i modyfikować już istniejące. |
|
|
![]()
Post
#5
|
|
Grupa: Zarejestrowani Postów: 111 Pomógł: 1 Dołączył: 24.12.2013 Ostrzeżenie: (0%) ![]() ![]() |
Bardziej chodzilo mi o sam dodatek. Przykladowo piszesz dodatek wyswietlajacy na stronie artykuly, wiec taki dodatek moglby zarejestrowac swoje przyciski na toolbarze. Dzieki temu, po zalogowaniu sie jako administrator nie mialbys przyciskow do edycji, badz usuniecia artykulu obok jego nazwy na stronie, tylko na globalnym pasku narzedzi na tabie 'Artykuly'. Tutaj nie decydowalby uzytkownik, czy administrator strony, tylko osoba tworzaca dane rozszerzenie do systemu. Taki toolbar dawalby mozliwosc wykonania podstawowych czynnosci administracyjnych, bez koniecznosci logowania sie do panelu administratora, ale to jakie przyciski by sie tam znalazly, zalezaloby od wlaczonych dodatkow.
Wyobrazalem sobie zatem, ze np z rejestru, dodatek bedzie mogl pobrac sobie objekt toolbara i dodac do niego dowolna ilosc zakladek/przyciskow, a nastepnie na tej podstawie wygenerowany zostanie widok. Ten post edytował q.michal 24.03.2016, 11:04:52 |
|
|
![]()
Post
#6
|
|
Grupa: Zarejestrowani Postów: 516 Pomógł: 63 Dołączył: 27.08.2012 Ostrzeżenie: (0%) ![]() ![]() |
Nie zrozumiałem wcześniej do końca tego co chcesz zrobić. W takim razie powinieneś poczytać o wzorcu Registry.
|
|
|
![]()
Post
#7
|
|
Grupa: Zarejestrowani Postów: 111 Pomógł: 1 Dołączył: 24.12.2013 Ostrzeżenie: (0%) ![]() ![]() |
Powracajac do pierwotnego pytania. Zastanawiam sie jak to rozwiazac od strony designu.
Czy wybrac wariant A, tj. z objektu toolbara tworzyc taby, a z tabow przyciski i separatory, czy wariant B - przyjac ze wszystko jest objektem i przekazywac objekty przyciskow/separatorow/list/itp do taba a taby do toolbara? Ktos moze sie wypowiedziec, co bedzie bardziej optymalne, ew. jakie moze niesc za soba limity? |
|
|
![]()
Post
#8
|
|
Grupa: Zarejestrowani Postów: 516 Pomógł: 63 Dołączył: 27.08.2012 Ostrzeżenie: (0%) ![]() ![]() |
To wg mnie 2 sposób będzie lepszy. Napisałbym to w tym kierunku:
To tylko bardzo ubogi przykład. Sorki za ewentualne błędy w składni, ostatnio dużo pisze w innych językach EDIT: Lepiej by to wyglądało jednak w oparciu o interface'y niż dziedziczenie - w tym konkretnym przykładzie. Mam teraz na biurku browarka, tak więc nie chce mi się teraz tego poprawiać. Mam nadzieje jednak że wiesz o co mi chodzi Ten post edytował gitbejbe 24.03.2016, 19:44:37 |
|
|
![]()
Post
#9
|
|
Grupa: Zarejestrowani Postów: 111 Pomógł: 1 Dołączył: 24.12.2013 Ostrzeżenie: (0%) ![]() ![]() |
Wszystko jasne, wielkie dzieki!
|
|
|
![]() ![]() |
![]() |
Aktualny czas: 20.09.2025 - 04:58 |