Pozwól mi wyjaśnić:
@raynos napisał:
Kontrolery słuchać na wejściu. Oznacza to, że kontrolerzy nasłuchują zdarzeń od węzłów DOM
osobiście, mimo że zgadzam się z pierwszym stwierdzeniem, nie podoba mi się interpretacja.
Podążanie za tym stwierdzeniem oznacza, że kontroler musi znać każdy przycisk/pole tekstowe/element w interfejsie użytkownika i jego identyfikator/selektor.
Preferuję zdarzenia semantyczne Zobacz ogień, takie jak "languageSelected" lub "searchRequested" i dodaj odpowiednie dane do zdarzenia.
więc typowy przepływ byłoby, że widok sprawia pewne UI (powiedzmy, że ma pola wyszukiwania i przycisk), kiedy użytkownik kliknie przycisk - The View obsługuje zdarzenie i pożary własną „searchRequested” zdarzenie. Zdarzenie to jest obsługiwane przez Kontroler, który nazwałby model Model z prośbą o wykonanie wyszukiwania. po zakończeniu, Model uruchomi evnet "searchResultsUpdated", który będzie obsługiwany przez View powodując wyświetlenie wyników.
jeśli teraz zdecydujesz się zmienić projekt swojej aplikacji, aby wyświetlać łącza do wyszukiwanych haseł zamiast pola wyszukiwania i przycisku (lub nawet jeśli masz obok siebie - lub na różnych ekranach) jedyną rzeczą, którą musisz zmiana to Wyświetl.
technicznąej side-note: Jeśli przy użyciu JQuery i zakładając swój pogląd jest javascript obiektu można korzystać
$(view).triggerHandler(
$.Event('eventName',{'object:'with','more':'event','related':'data'})
);
do ognia zdarzenie
And
$(view).on('eventName',handler);
aby słuchać i obsługiwać wydarzenie.
Kontrolery nasłuchują na wejściu. Oznacza to, że kontrolery nasłuchują zdarzeń z węzłów DOM. – Raynos
@Raynos: masz na myśli to, że widok przypisuje element dom i onclick, a wewnątrz tego onclick uruchamia zdarzenie, które kontroler musi zasubskrybować? dzięki! – tau
Nie, widok nie ma biznesowych rozmów z kontrolerem. Kontroler pobiera w jakiś sposób uchwyt na węźle domowym i dołącza sam program obsługi. – Raynos