Witam

Na wstępie chcialbym zaznaczyć, że stworzenie tego nie nastręcza mi problemów. Bardziej nie daje mi spokoju czy aby nie robię tego jakoś naokoło, nieoptymalnie. Być może istnieje jakiś wygodniejszy nieoczywisty dla mnie sposób?

http://jsfiddle.net/WiruSSS/zPXUK/

Robisz to dobrze - tak jak się powinno. Inne uwagi:

-
Jest to nieczytelne i wolne( , jeśli kilka ms ma dlakogolwiek znaczenie ). Użyj .find() z li:first-child.

-
Skoro >> nie jest linkiem, nie używaj elementu <a>

Ja bym nie robił takich rzeczy z definicjami zmiennych jak wymienianie ich po przecinku w sytuacji gdy przypisuje się do nich wartości z funkcji.
Coś takiego wygląda tylko wtedy, kiedy wchodzi w rachubę proste przypisanie wartości albo same deklaracje:

[JAVASCRIPT] pobierz, plaintext 
var zmienna, string, tekst, pole, div;
[JAVASCRIPT] pobierz, plaintext 

[JAVASCRIPT] pobierz, plaintext 
var zmienna = 2 , string = "Witaj świecie", tekst, pole, div;
[JAVASCRIPT] pobierz, plaintext 

Chociaż i tego rzadko używam bo w programowaniu obowiązuje zasada - deklaruje zmienne jak najbliżej miejsca w którym zostaną użyte.

Kolejną rzeczą, która mi się rzuca w oczy - w JS zazwyczaj nie używa się nazw obiektów z dużej litery - "SlideMenu" jest źle, powinno być "slideMenu". Duże litery są pozostawione dla klas (a w JS to się nazywa konstruktor).

Zauważ też, że "show.parent().hide()" i "show.parent().show()" wygląda idiotycznie Może znalazłyby się lepsze nazwy dla zmiennych "show" i "hide" ?

Dla zaawansowanych: Nie chce mi się przepisywać Twojego kodu ale - funkcje anonimowe, które podajesz w $.click są na tyle rozbudowane, że możnaby im nadać osobne nazwy i odwołać sie do nich w innych polach obiektu "slideMenu", a w init zrobić tylko obiekt.click(pokaz.bind(this));

Generalnie to wszystko to są takie igraszki dla efektu. Można dzięki temu, oczywiście zbudować sobie zaplecze elementów do ponownego użytku. Spróbuj jednak wymyślić sobie jakąś większa aplikację, która zmusiłaby Cię do tworzenia modułów i używania wzorców projektowych, jeśli chcesz poznać "smak prawdziwego programowania" (nie taki fajny swoją drogą ).

..hmm ..nie do końca się zrozumieliśmy ...to jest przykład napisany z palca do pokazania co chcę osiągnąć. Nazwy zmiennych akurat tutaj nie mają znaczenia, chodzi mi o samą konstrukcje z użyciem 2 buttonów, z których zależnie od sytuacji kolejny jest ukrywany. Bardziej chodziło mi o opinię, czy da się coś takiego uzyskać prostszą drogą (np z użyciem jakiegoś zwykłego toggle).

Obecnie piszę edytor graficzny działający w przeglądarce, więc "duże projekty" nie są mi obce

Znam wzorce projektowe i wiem jakie są konwencje. Ale chyba to nie zmusza mnie do sztywnego trzymania się wszystkoego co ktoś tam sobie ustalił. Akurat mnie wygodniej obiekty literałowe nazywać duzymi literami (chociaz kłóci się to z ogólnie przyjętymi zasadami) ..każdy ma jakieś tam swoje przyzwyczajenia.

Co do ścieżek dostępu do drzewa, szczerze powiedziawszy nie zastanawiałem się czy szybciej zadziała find() czy może parent (chociaż akutar tutaj faktycznie wygląda to nie za ciekawie ). Używam tego co mnie osobiście szybciej na pierwszy rzut oka zasugeruje do czego się odwołuje (a skoro takie metody są udostępnione to dlaczego ich nie uzywać?). Ale tak jak pisałem, w tym przykładzie po prostu napisałem wszystko z palca, dla pokazania samego efektu jaki chcę uzyskać. Także jesli mogę prosić o udzielenie mi porady, która ma związek z moim zapytaniem.

Dla jasności jeszcze raz napiszę: Czy da się owy efekt uzyskać w prostszy sposób (w sensie np jeden przysisk + jakieś toggle). Czy muszę rozgraniczać się do zdarzenia chowania menu osobno a do zdarzenia wysuwania menu osobno?

[edit]

..a jeszcze odnośnie var i przecinków. Tutaj chyba też jest kilka zdań na ten temat. Ja się trzymam konwencji Stoyana Stefanova. Zysk wydajności wg zasady deklaracji jak najbliżej użycia wg mnie jest na tyle znikomy, że wolę jednak bardziej czytelny dla mnie sposób, wpierw wszystko deklaruję, potem używam.

[edit]

...w "życiowym" przykładzie znaczniki a maja zarówno zawartość jak i zdefiniowany href [edit]..ok chodziło ci o przycisk ukrywający i wysuwający menu, znów nie doczytałem

[edit]

kamil4u ..od razu rzuciły mi się w oczy uwagi a nie zauważyłem, że pierwsze twoje zdanie tyczy się dokladnie tematu

[edit]
...dziękuję za wszystkie sugestię ..a żeby w oczy nie koliło troszkę przepiszę ten przykład ..a nóż komuś się do czegoś przyda

[edit]

ale się editów uzbierało, prosiłbym jeszce o wyjaśnienie tego

[JAVASCRIPT] pobierz, plaintext 
obiekt.click(pokaz.bind(this));
[JAVASCRIPT] pobierz, plaintext 

[edit]

..kolejny edit ...troszkę zmodyfikowałem skrypt być moze teraz mniej kole w oczy

Wow... ok, z mojej strony powiem tak:


tutaj mi akurat o wydajność nie chodziło... bo ja właśnie uważam deklarowanie zmiennych tam gdzie się pojawiają za bardziej czytelne w większości przypadków, są od tego wyjątki.

Na temat Function.bind(context) czyli obiekt.click(pokaz.bind(this));... ta funkcja zwraca nową funkcję, która zawsze wykona się w kontekście tego co jest w zmiennej "context", czyli w twoim przypadku - "this". Chodzi ot to, że używając tego podejścia, które przedstawiłeś - gdybyś w którejś z tych funkcji anonimowych użył słowa this to miałbyś w nim pewnie obiekt DOM na którym jest wykonywany click. Używając funkcji "bind" w kontekście zawsze będziesz miał obiekt "slideMenu".

Gdybyś miał coś takiego, bez używania "bind":

[JAVASCRIPT] pobierz, plaintext 
 showMenu: function()
    {
        var menu = $(this).children();
 
        menu.find('li:first-child').hide();
        menu.find('li:last-child').show();
        menu.animate({'left': 0});
 
        this.hideMenu(); // tu wyskoczyłby Ci error !!!!
    },
 
[JAVASCRIPT] pobierz, plaintext 

a z użyciem bind... wszystko by było ok (pomijając fakt, że 2 funkcje animate by sie ze sobą pogryzły, ale nie chodzi tu o funkcjonalność tylko logikę "bind").

Mi teraz Twój kod bardzo się podoba. JS to język programowania, a mówiąc po polsku nie bełkoczemy tylko mówimy do rzeczy .

Przy okazji zauważ, że gdybyś z innego miejsca skryput chciał zamknąć "slideMenu" to wystarczy slideMenu.hideMenu();


EDIT: Jeszcze jedna sprawa: zamiast pisać w każdej metodzie (funkcji) "var menu = $(this).children();" mógłbyś to zapisać właśnie w obiekcie "slideMenu", ale do tego potrzebujesz konstruktora "SlideMenu".... aby każde menu było osobnym obiektem SlideMenu. No ale to już jak chcesz.

..no niestety z moim programowaniem tak jest, zajmuję się tym od około 10 lat, ale od początku byłem samoukiem, a kod który pisałem w 90% przypadków nie trzymał się żadnych wzorców, tylko był pisany jak leci.

Jednak od jakiegoś czasu staram się uporzadkować to co do tej pory się nauczyłem, zainwestowałem troszkę w ksiązki i na nowo odkrywam programowanie. Dopiero teraz zaczyna mi to przynosić naprawdę sporą frajdę

Wracając do przykładu. Własnie chciałem uniknąć tutaj tworzenia nowych obiektów przypisanych konkretnemu menu. Jednak natknąłem się na pewien problem, przez który nie wiem czy nie będę musiał jednak z konstruktora skorzystać. Chcę mieć możliwość ustawiania menu zarówno po lewej stronie jak i po prawej.

Masz jakiś pomysł w jaki sposób najlepiej to zrobić? Poczyniłem próby z dodatkowymi zmiennymi przechowującymi position().left. W momencie kiedy jest większe od zera, animacja się winna przestawić na right, no i buttony oczywiśce też. Tylko nie wiem czy to znów w miarę optymalne. Bo kod już tak ładnie jak teraz z takimi warunkami się nie prezentuje

Chciałbym uniknąć zbędnej konfiguracji, wolałbym aby wszystkie menu uruchamiały się automatycznie w zależnosci do której strony okna przylegają (wiadomo, że o to aby menu przylegało do konkretnej strony, będzie musiał sobie zadbać programista korzystający ze skryptu, definiując to w arkuszu stylów za pomoca position lub float)

[EDIT]

...czy zastosowanie czegoś takiego będzie sie bardzo kłóciło z przyjętymi konwencjami?

[JAVASCRIPT] pobierz, plaintext 
var SlideMenu = function()
{
	//konstruktorek
}
 
$(document).ready(function(){
 
	$.each($('.slide-menu'), function(){
		new SlideMenu(this);
	});
 
});
 
 
[JAVASCRIPT] pobierz, plaintext 

...tak jak piszesz zastosowanie konstruktora bardzo mi ułatwi sprawę i jednocześnie pozwoli na zachowanie przejrzystego kodu, tylko nie wiem czy takie "szastanie" $(document).ready() powinno mieć miejsce ...to by mi znów zapewniło uruchomienie skryptu przez zdefiniowanie samej klasy dla menu, czyli brak zbędnej jak dla mnie konfiguracji i uruchamiania każdego menu z osobna.

Mam wrażenie, że powinienem do tego użyć wzorca factory. Jednak właśnie to jest mój główny problem. Nie zawsze jest dla mnie oczywiste, z którego wzorca najlepiej skorzystać

Kilka spraw odnośnie tego kodu:

- nie dajesz osobie korzystającej z tej klasy "SlideMenu" możliwości wybrania tego co będzie sliderem.
- "Własnie chciałem uniknąć tutaj tworzenia nowych obiektów przypisanych konkretnemu menu" - to kompletnie błędne rozumowanie, właśnie o to chodzi, że każde menu to osobny obiekt
- nie CSS decyduje o tym po której stronie ma być slider. Tu mieszasz reprezentację z logiką. To skrypt ma decydować po której stronie ma być slider.



Jak wyżej plus jeszcze jedno - właśnie o to chodzi, że pisząc jakikolwiek kod który ma być ponownie użyty - musisz udostępnić zmienne konfiguracyjne.

Programista (kod kliencki) sam decyduje jaki plugin / bibliotekę chce użyć - i robi to w $.ready(). Ty tylko tworzysz funkcjonalność, dając mu do dyspozycji zmienne konfiguracyjne. Tutaj pojawia się też jeszcze jedna wada Twojego podejścia - że w CSS chcesz zawrzeć logikę tego skryptu. Rozbijasz API na CSS i JS, co już jest nie do przyjęcia.

Jeśli już chcesz odpalać menu "hurtem" to albo pozwól na to programiście albo utwórz nową klasę, która będzie zarządzać instancjami menu.

Wzorzec fabryki na nic tutaj się nie zda - nie do tego służy.

Tutaj jest kod: http://jsfiddle.net/a4Bpv/3/

powinien działać w wersji bez głupiego "JsFiddle", w czystym HTMLu.

A guzik, akurat z tym się nie zgodzę. To menu ma dziełać również bez js, ale choćby nawet było inaczej. Js nie powinno decydowac o jego położeniu. Użytkownik ma sobie stworzyć menu, ustawić gdzie chce, i jeśli będzie chciał aby się chowało, wystarczy, że nada klasę, .slide-menu

Przyjrzyj się temu jeszcze raz. Skrypt sprawdza szerokość menu oraz jego położenie względem rodzica, u na podstawie tego decyduje jak ma się animować. Po co do tego zbędna konfiguracja?

Źle to robisz, nie powiem Ci czemu bo do tego wystarczy odrobina wyobraźni.

Ale to, że robię to inaczej niż zrobiłby to kto inny, nie koniecznie oznacza że jest źle
Jeśli tak się upierasz to bardzo proszę zaprezentuj mi fragment kodu odpowiadający (wg Ciebie w warstwie logicznej bo dla mnie to zawsze będzie warstwa prezentacyjna) ustalenie pozycji menu za pomocą javascript?

na pewno da się skrócić kod. To co mi się rzuca w oczy, to straszne ilości zduplikowanego kodu:



to masz z 3 razy w różnych funkcjach powtórzone.

tak samo to:


a powtarzanie sie jest bez sensu, bo będziesz chciał coś zmienić - 3 razy więcej roboty.
W zasadzie dobrze byłoby wydzielić powtarzający się kod do jakiejś osobnej funkcji pomocniczej, np.:


a potem zamiast:

wywołujesz tylko funkcję i przypisujesz zmienne z funkcji:



Nie musisz. Możesz zrobić to w jednej funkcji. Na dobrą sprawę showMenu i hideMenu robią dokładnie to samo, różnią się tylko jedną linijką:
w hide jest

a w show


czyli możesz zamiast zrobić osobne funkcję dać jedną funkcję showHideMenu, i showHideMenu(true) oznacza pokazanie, showHideMenu schowanie:

coś jak to (nie chce mi się tego testować czy wszystko się odpala, ale w zarysie tak mniej więcej).

No i żeby zrobić "lukier składniowy", możesz zostawić funkcje showMenu / hideMenu, ale w ten sposób, że będą odwoływać się do showHideMenu:


tym sposobem dalej będziesz mógł pisać hideMenu() / showMenu().

EDIT:
albo zrób tak jak kolega napisał, z utworzeniem konstruktora i osobnego obiektu do każdego menu. Whatever works Ważne, żeby nie powtarzać zbyt dużej ilości kodu (bo tak jak teraz masz jest tragicznie pod kątem powtarzania). Zresztą wsadzenie czegoś w jeden obiekt wcale nie przeczy temu co napisałem.



w JavaScript do zalecanych praktyk należy deklarowanie zmiennych na początku funkcji - chyba wiesz dlaczego (dla postronnych - chodzi o to, że zasięg zmiennych deklarowanych przez 'var' jest na całą funkcję (a nie na blok kodu, jak to jest np. w C++)


to po której stronie/w którym miejscu ma być slider, to właśnie warstwa reprezentacji i powinno to być ustawiane w HTML/CSS.

Ok. To bawcie się w deklarowanie zmiennych konfiguracyjnych w CSS. Powodzenia w momencie kiedy przyjdzie 10 nowych zmiennych konfiguracyjnych albo 10 nowych sposobów reprezentacji. I tak powstaje "modularny" kod. Śmiechu warte.

EDIT: Obiektów w JS nie nazywa się "showHideMenu" bo to jest idiotyczna nazwa. Używa się do tego setterów. Dla rozgrzewki intelektualnej pozostawię to do przemyślenia czytającemu.

Zamiast się mądrzyć i odsądzać od czci i wiary innych userów, jakbyś był jakimś guru, przeczytaj jeszcze raz mój post, tym razem ze zrozumieniem.


nie pisałem o obiektach, tylko o funkcjach:

czyli możesz zamiast zrobić osobne funkcję dać jedną funkcję showHideMenu, i showHideMenu(true)
(pomijam to, że każda funkcja w języku JavaScript to też obiekt, bo nie o to tutaj chodzi, tylko o to, że nie doczytałeś dokładnie mojego posta. Mowa o zwyczajnej funkcji, która jest w stanie pokazać/schować menu, a nie o jakimś wysublimowanym obiekcie).

to, że nie czytasz dobrze postów, zauważyłem już na początku tego wątku, bo napisałeś:

przecież show() i hide() to nie zmienne, a nazwy metod jQuery. Jeśli wygląda to idiotycznie, pretensje do Johna Resiga.


setterów i getterów ogólnie się nie powinno raczej używać, ale zostawmy ten temat, bo to długa dyskusja.



od wyglądu i układania layoutu jest CSS i HTML, takie są ogólne prawa tworzenia stron internetowych
Oczywiście, są rzeczy, które stricte do wyglądu nie należą (wtedy bardzo często w przypadku różnych pluginów do jQuery czy bibliotek JSowych należy podać parametry konfiguracyjne w konstruktorze danego obiektu (coś a la new SlideMenu({menuType:'profesionalMenu', name:'menu główne', hoverBehavior:'slide', delay:1000}), ale to akurat, po której stronie ekranu jest menu i czy na górze czy na dole strony to akurat normalne, rutynowe zadanie dla HTMLa i CSSa, a nie dla JavaScriptu (który służy bardziej do logiki, interakcji, obsługi zdarzeń).

W ogóle źle na to patrzysz. To nie jest "konfiguracja" a raczej warstwa wyglądu, widoku. Zamiast się mądrzyć bez zrozumienia specyfiki stron internetowych, poczytałbyś wpierw o wzorcu MVC i o ogólnych trendach w tworzeniu stron internetowych. Zobaczyłbyś np. jak jest zbudowana biblioteka Twitter Bootstrap - tam się wszystko "konfiguruuje" w HTML).


"jak ktoś ma młotek, wszędzie będzie widział gwoździe". Problem jest taki, że patrzysz na to z perspektywy tylko i wyłącznie programisty, co jest podstawowym błędem - stron internetowych się nie programuje, a raczej wszystko składa w całość - jest tu trochę programowania po stronie serwera(PHP itp.), trochę kodu HTML/CSS, trochę programowania w JavaScripcie, trochę grafiki w postaci JPG/PNG, trochę baz danych - w każdym razie "tworzenie stron internetowych" to coś więcej niż "programowanie", które jest zaledwie jedną z części układanki.

Funkcja jest obiektem w JS. Ale skoro tego nie wiedziałeś, to tutaj kończy się nasza rozmowa.


https://www.youtube.com/watch?v=bzkRVzciAZg

Właśnie w idealny sposób pokazałeś, że nie umiesz czytać ze zrozumieniem, albo jesteś zwykłym trollem, nie wiem.

Umiejętność rozumienia tekstu pisanego w języku polskim się kłania.





Albo cierpisz na dysleksję albo trollujesz. Z agresywnego tonu twoich wypowiedzi wnioskuję, że to drugie. Więc dobranoc.

To po co wcześniej ta uwaga:


Problem nie tkwi w tym, że ja rzekomo nie potrafię czytać ze zrozumieniem, lecz w tym że Ty nie piszesz z logiką.

Jest tysiąc argumentów na to, że rozwiązywanie tego przez CSS jest głupotą, z których wymienię:
- problemy z integracją skryptów z systemami CMS jako pluginy, gdyż zmienne z bazy danych są przekazywane do JS przez HTML, a nie przesyłane zapytaniem przez CSS.
- rozrzucenie API pomiędzy JS i CSS
- CSS służy stylowaniu pojedynczych elementów, a nie definiowaniu zachowania dynamicznej zawartości inicjowanej przez JS, poza trywialnymi przypadkami - kiedy animacja służy właśnie jedynie samej prezentacji


Właśnie dzięki takim "bootstrapom i node.js -om" i innym zboczonym podejściom do tworzenia stron internetowych "technologie webowe" stoją w miejscu albo ciągle są problemy z dopasowaniem API, z jednego prostego powodu - takie podejście nie jest skalowalne.

Ty nie dałeś jednego logicznego argumentu, a jedynie ciągle opowiadasz, że to jest warstwa prezentacji. O ile faktem jest, że położenie obiektu można zdefiniować w CSS - głupotą jest definiowanie zmiennych konfiguracyjnych skryptu w CSS. Jeśli za coś odpowiada skrypt - powinien odpowiadać za to do końca . Wy chcecie chwycić dwie sroki za ogon ale wam to nie wyjdzie i z czasem się wam wszystko rozpadnie w rękach.

...ale się gorąco zrobiło. W zasadzie skypt miał być do moich celów a ja specjalnej konfiguracji nie potrzebuję (wystarczy mi jedynie ustalić czy dane menu ma być na starcie schowane czy wysunięte). Postaram się jednak napisać ten kod najlepiej jak potrafię. Wszystkie uwagi są dla mnie bardzo istotne także bardzo za nie dziękuję. no i licze też na rozluźnienie atmosfery, przecież od tego nie zależy niczyje życie i świat się nie zawali



Do tego się odniosę bezpośrednio bo tutaj widzę że chyba nie do końca się zrozumieliśmy i być może dlatego taka różnica zdań.
w projekcie nad którym pracuje, potrzebuję 4 takie menu. Mają one działać zarówno z JS jak i bez niego o czym zresztą pisałem. Pisząc działają, miałem na myśli, da się w nie kliknąć ...mają być po prostu zawsze wysunięte. Mają one być w konkretnych miejscach na stronie i nie mogę tego uzależniać od javascriptu, dlatego też zrobiłem to tak, że menu samo wykrywa do której krawędzi przylega i od tego uzależnione jest czy chowa się w lewo czy w prawo. Wydaje mi się to najrozsądniejszym rozwiązaniem

Jeśli chcesz mieć frajdę z tego co robisz - rób elementy, które będziesz mógł wykorzystywać ponownie i twórz dla nich API + dobrą dokumentację. Kiedy przyjdzie do kolejnego projektu z podobną funkcjonalnością - przypomnisz sobie, że już coś takiego masz w bibliotekach, a jeśli trzeba będzie - dodasz nową funkcjonalność. W ten sposób - Twoja biblioteka się polepszy, a kod pozostanie modularny, a nie zasmrodzony skryptami tu i tam.
Weź na przykład jakiś Lightbox czy Colorbox, albo te Countdowny. Mógłbym też dać przyklad ExtJs Sencha Labs - kompletna bibltioteka GUI, która powstawała stopniowo czy TinyMCE(niesamowite to jest jak ten edytor można wzbogacać i do jakiego stopnia rozwinął się tam system pluginów).