2009-08-31 13 views
11

Jakie wzorce interfejsu użytkownika zwykle używasz w JavaScript?Wzory UI w kodzie JavaScript

Przez wzorce UI mam na myśli najlepsze praktyki, które należy stosować do budowania i organizowania interfejsu użytkownika wygenerowanego/zarządzanego z JavaScript (poza bibliotekami takimi jak jQuery lub YUI).

Na przykład, jeśli pochodzisz ze świata .NET, znasz rodzinę wzorców MVC (Model-View-Controller). W świecie WinForm i ASP.NET spotkasz Model-View-Presenter. W WPF najprawdopodobniej znajdziesz podejście MVVM (Model-View-ViewModel).

A co z JavaScript?

+0

Nie ma powodu, dla którego MV [C | P] nie miałby zastosowania - jego ładny język niezależny. – Chii

Odpowiedz

7

Wzorce są zwykle nieakceptowane językowo. Jeśli wzór ma wartość, w przypadku niektórych przypadków brzegowych ma wartość niezależnie od używanego języka lub technologii. Weź MVC. Koncepcja oddzielania modelu od widoku od kontrolera ma wartość niezależnie od tego, czy model jest zaimplementowany za pomocą RDBMS, czy innej technologii, niezależnie od tego, czy widok jest HTML, czy Swing, czy X.

Gdzie widać pewne wzory zastosowane więcej w jednej technologii niż innej zwykle oznacza po prostu, że twórcy technologii mieli szczególne podejście, które wspierali bardziej niż inni.

JavaScript sam w sobie nie narzuca żadnego konkretnego wzoru. Niektóre środowiska JavaScript, takie jak YUI, Dojo lub Glow, będą prowadzić Cię w jednym kierunku bardziej niż innym.

Pod koniec dnia przyjrzyj się problemowi, który rozwiązujesz, zasobom i doświadczeniu, które posiadasz, i postępuj zgodnie z wzorcami, które mają sens.

+0

Dziękuję za odpowiedź, T.J! Nie zaznaczyłem tego wcześniej jako odpowiedzi, ponieważ miałem wątpliwości. Myślałem, że powinno być coś bardziej popularnego niż reszta. Ale wygląda na to, że w JavaScript World używasz bibliotek lub adoptujesz coś z innych platform (MVx), które lepiej pasuje do twojego problemu. – Anvaka

1

Wiem, że nie ma jeszcze określonych wzorów dla Javascript. Ale myślę, że istnieje potencjał dla czegoś podobnego do widżetów (komponent). Ponieważ głównie używamy javascript do wzmocnienia naszego kodu html. Logiczne jest, że powinniśmy połączyć nasz każdy obiekt javascript z tagiem html. Mamy tutaj coś takiego jak Model (jsObject) + Widok (HTMLreprezentacja). Aby uzyskać MVC potrzebujemy kontrolerów i mamy dla tego Wydarzenia. W takim przypadku będziemy mieli łatwo skondensowane komponenty extensibel.

na przykład:

// this is a part of some FormValid.js 
<script> 
function FormValid(){ 

} 

FormValid.prototype.validate=function(){...} 
</script> 

//this is our HTML 
<form id="form1"...onsubmit="this.jsObject.validate();"> 
</form> 

<script> 
//all the following stuff could be solved in one line, but you need to create some helper. Like Components.Attach("FormValid").to("form1"); 
var newObj=new FormValid() 
var form=document.getElementById("form1"); 
from.jsObject=newObj; 
newObj.htmlObj=form; 
</script> 

też mam pomysł wykorzystania silników szablonów jak Zparser oddzielić widok i model. W tym celu tworzę bibliotekę js, więc teraz jestem w tej kwestii.

Mamy obiekt podstawowy z metodą , zobacz. Wszystkie nasze klasy mają go jak prototyp na końcu. Ta metoda pobiera właściwość klasy szablony i za pomocą niektórych parser szablony generuje HTML na podstawie naszego modelu. Ten kod HTML jest wstawiany do węzła htmlObj, więc WIDOK naszego obiektu jest aktualizowany. Jest to po prostu pomysł, a nasz kod staje:

// this is a part of some FormValid.js 
<script> 
function FormValid(){ 

} 
Components.extendCore(FormValid); 

FormValid.prototype.validate=function(){...} 
</script> 

FormValid.prototype.templates={ 
    main:'<form class="form1"...onsubmit="this.jsObject.validate();">...</form>' 
} 

//this is our HTML 
<div id="form1"></div> 
<script> 
Components.Attach("FormValid").to("form1"); 
</script> 

nadal uważam ostatni inline <script> powinny być tam i to nie jest mieszanie logiki z reprezentacji, ponieważ jest to składnik - kawałka. Nie ma znaczenia bez siebie. W rzeczywistości powinno to być częścią aplikacji. Coś w rodzaju html komponentu (w jednym przykładzie to div) powinno być zdefiniowane i opakowane w komponent, który automatycznie doda skrypt i identyfikatory.

Teraz. Pokazałem wam 2 przykłady i wyjaśnię, dlaczego drugi jest zbyt szczegółowy.
Wszystko jest w zakresie dostępności i wydajności (oraz wycieków pamięci). Jeśli odświeżysz wszystkie html komponentu - zacznie migać, będziesz musiał również skonfigurować wszystkie zdarzenia dynamiczne i sprawdzić wszystko pod kątem wycieków pamięci. Ale główny problem, jeśli JS się nie powiedzie - twoja aplikacja nic nie wskaże.

Więc wolę mieć wybór między tymi dwoma :) i używać wszystkiego na swoich miejscach.

+0

Widgety/komponenty są już objęte YUI, jQuery, ExtJS, Dojo itp. Pytanie zadawało pytania o sposoby podejścia "poza" takimi bibliotekami. –

+0

Widzę twój punkt Djko! Z pewnych powodów nie czuję się pewnie w tej technice. Przypomina mi to niechlujny kod ASPX + Behind, ale w tym przypadku jest tak, jakby kod z tyłu został zapisany bezpośrednio na stronie ASPX (no cóż, powiedzmy, że zapomniałem o ). Interfejs użytkownika działa jak widok i kontroler w tym samym czasie. Model powinien wiedzieć wiele, aby dokonać dynamicznych zmian w interfejsie użytkownika (na przykład zmienić jego klasę) ... Może mógłbyś podać kilka dobrych przykładów z demonstracji tego pomysłu? – Anvaka

+0

Rozumiem twoje obawy, ale dla rozwoju strony klienta funkcja JavaScript działa z interfejsem użytkownika. Powinien więc dużo o tym wiedzieć i wchodzić w interakcje z nim głęboko. Z drugiej strony, mogę pokazać przykład, gdzie IT można oddzielić widok i model. Zobacz zaktualizowaną odpowiedź. –

4

Chciałbym polecić Ross Harmes & Książka Dustina Diaz'a, Pro JavaScript Design Patterns, zdecydowanie najlepsze źródło informacji na ten temat i zdecydowanie warte przeczytania.

Jest tam również bardzo interesujący artykuł na temat JavaScript MVC w najnowszym numerze A List Apart.

+0

+1 w 2009 roku, ale prawdopodobnie już nie jest prawdą. Ta książka pochodzi z 2007 roku, bez wątpienia potrzebuję aktualizacji. Może chcesz zaktualizować tę odpowiedź. Czytałem i cieszyłem się [Obsługiwalny JavaScript] (http://amzn.com/1449327680), który jest doskonały, ale dość krótki. –

1

Dobrym podejściem do budowania aplikacji GUI jest to, że z przeglądarki:

  1. z użyciem znaczników dla układu UI
  2. użyciu JavaScript logikę interfejsu
  3. za pomocą CSS dla UI stylizacji

Większość nowoczesne frameworki GUI (ExtJS, Dojo itp.) oferują API, które bardzo pomagają budować GUI wyłącznie w JavaScript. Ale jest jeszcze jeden framework GUI Ample SDK, który przynosi wspomniane wcześniej rozdzielenie obaw. Pozwala na używanie języków XML (XHTML, XUL, SVG) do układu, CSS do stylu i DOM API dla logiki UI.

Aby zgrać aplikacji GUI po stronie klienta można użyć MVC lub trochę bardziej zaawansowany wzór PAC, jak w przypadku pierwszego - jest PureMVC realizacja dostępny

Spójrz na poniższym fragmencie (tylko obawy logiczny interfejs użytkownika, a nie logika aplikacji, które mają być zbudowane z MVC/PAC):

index.html

<script type="application/ample+xml"> 
    <xul:tabbox onselect="fOnSelect(event)" 
    xmlns:xul="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"> 
     <xul:tabs> 
      <xul:tab label="checkbox" /> 
      <xul:tab label="textbox" /> 
      <xul:tab label="datepicker" /> 
     </xul:tabs> 
     <xul:tabpanels> 
      <xul:tabpanel> 
       <xul:checkbox /> 
      </xul:tabpanel> 
      <xul:tabpanel> 
       <xul:textbox /> 
      </xul:tabpanel> 
      <xul:tabpanel> 
       <xul:datepicker /> 
      </xul:tabpanel> 
     </xul:tabpanels> 
    </xul:tabbox> 
</script> 

index.css

@namespace xul url("http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"); 
xul|tab:focus { 
    color: red; 
} 

index.js

function fOnSelect(oEvent) { 
    alert(oEvent.currentTarget.selectedItems.length) 
} 
+0

Brzmi interesująco. Słyszę o tym po raz pierwszy. Czy wiesz, jak popularne jest to podejście w świecie JS? Myślałem, że xul jest językiem używanym przez aplikacje Mozilli (tylko). – Anvaka

0

Wyjazd strona nazywa quince. Nie jestem pewien, ile wzorów tutaj jest wzorców ui javascript. Ale jest to całkiem niezłe źródło informacji dla wzorów UI.

+0

Dziękuję za referencję, Sandeep. O ile mi wiadomo, Pigułka mówi o najlepszych wzorcach użyteczności. Moje pytanie dotyczyło podejścia architektonicznego, używanego przez społeczność JavaScript do organizowania warstwy prezentacji. W każdym razie jeszcze raz dziękuję za wzmiankę o tym :). – Anvaka

0

Wzorce nie zawsze są agnostyczne. Wiele klasycznych wzorców projektowych nie ma sensu w JavaScript, ponieważ nie potrzebujemy wiele obejść, które rozwiązują w bardziej restrykcyjnych paradygmatach langauge.

Powód, dla którego MVC nie jest tak gorącym rozwiązaniem dla tworzenia stron WWW po stronie klienta, jest jednak bardziej sytuacyjny.

Po pierwsze uważam, że czas i ból sprawdziły się, że typowe aplikacje internetowe są najlepiej traktowane jako dwie osobne aplikacje. To, co dzieje się w przeglądarce i takie, które dzieje się na serwerze. Im mniej zależności między nimi ustalasz, tym bardziej elastyczne, łatwe w utrzymaniu i łatwiejsze w użyciu są aplikacje internetowe. M jest logiką biznesową (którą ludzie mają tendencję do niedokładnego łączenia z "bazą danych" IMO).

Problem z MVC w tym scenariuszu polega na tym, że nie chcemy ujawniać logiki biznesowej po stronie klienta, a próba zlikwidowania całej aplikacji w jedną ohydną konstrukcję ukrywającą podział na strony WWW okazała się bolesna, jak już wspomniałem.

Bardzo podobne wzorce, w których można oddzielić dane lub problemy z "modelem widoku", mogą jednak działać dość dobrze.