Wpis z mikrobloga

@NamalowanyPrzezSmutek:
Siema, Mirasy. Może mi ktoś poświęcić trochę czasu? Mam znowu problem z JS...
http://ksiazkakucharska.webatu.com/todo.php - tam tworzymy nowy 'task', w celach testowych trzeba stworzyć ze 2 minimum. Po kliknięciu na dodany task, rozwija się on odsłaniając panel dodatkowych akcji. Problem polega na tym, że po kliknięciu jednego elementu rozwijają się wszystkie pozostałe, analogicznie z ukrywaniem. Coś musiałem schrzanić przy mojej amatorskiej implementacji MVC.
Kod źródłowy: http://ksiazkakucharska.webatu.com/javascript/tasker.js

Jeśli się komuś będzie chciało pomóc koledze w potrzebie, to stawiam mu kiedyś piwo...Samemu już próbowałem chyba wszystkiego. Dziękuję z góry!
#webdev #programowanie #javascript #webdevhelp
  • 13
@NamalowanyPrzezSmutek: Hej :-) Oba TaskView nasł#!$%@?ą zdarzenia "onCollapse", dlatego tez oba rozwijają się lub zwijają po kliknięcu dowolnego z nich.

Dlaczego po prostu nie nadasz na bezpośrednio na $(#task) zdarzenia onclick które wykona showActionPanel()? Definowanie customowego eventa do takiej rzeczy jest dość dziwnym podejściem :-)
@NamalowanyPrzezSmutek: możesz np. w momencie wywoływania zdarzenia przekazać mu w argumencie id wybranego li np. tak:

event.id = _id;
document.dispatchEvent(event);

a potem wykorzystac w updacie:

this.update = function(e) {
if(!that.model.getIsCollapsed()) {
that.hideActionPanel(e.id);
} else {
that.showActionPanel(e.id);
}
}

this.showActionPanel = function(id) {
console.log(id);
$('#' + id).find('div.actionPanel .editBtn').bind('click', editTask);
$('#' + id).find('div.actionPanel').slideDown(400);
}



this.hideActionPanel = function(id) {
$('#' + id).parent().find('div.actionPanel').slideUp(400);
}

Wtedy updajt dalej wykona się 2 razy, ale collapsuje tylko wybrany
@Distiara: A samo dispaczowanie i nasłuchiwanie zdarzenia jest okej? Bo początkowo chciałem nasłuchiwać sam model, ale okazało się, że można eventy dodawać tylko na elementy DOM-u, a nie na same obiekty. Wtedy delikatna panika i jakoś przyfarciłem z tym emitowaniem zdarzenia przez document. Chyba nie ma znaczenia w tym przypadku?
@NamalowanyPrzezSmutek: raczej nie, wątpie? Tzn. ja w ogóle pierwsze się spotykam żeby ktoś bawił się w MVC po stronie klienckiej, więc guru i wyrocznia ze mnie nie jest :-) Natomiast wg mojego rozumienia Controller powienien zwracać widok. Czyli w metodzie kontolera musiłbyś tworzyć widok na nowo i w konstrutorze widoku na podstawie przekazanego modelu determinować czy jest panel otwarty czy zamknięty a następnie ładować zawrócony widok potem bezpośrednio no diva.

Natomiast
@Distiara: Ja inaczej rozumiem ten pattern. Uczyłem się go z ebooka Advanced Game Design in Actionscript 3.0. Według niego to wygląda tak:
- model to agregat danych, który nie ma wiedzy o niczym poza sobą, gdy zmienią się jego dane, emituje zdarzenie CHANGE, które zainteresowani będą sobie mogli podsłuchać.
- widok odpowiedzialny jest za prezentację danych, nasł#!$%@? zmian w modelu i na ich podstawie updejtuje się, odpowiedzialny jest też za przechwytywanie
@NamalowanyPrzezSmutek: zaciekawiłeś mnie tematem ^^. Znalazłam taki artykuł:

[http://addyosmani.com/blog/understanding-mvc-and-mvp-for-javascript-and-backbone-developers/](http://addyosmani.com/blog/understanding-mvc-and-mvp-for-javascript-and-backbone-developers/)
Bo to co przedstawiłeś na pewno nie jest takim "klasycznym" MVC jaki się robi po stronie serwerowej. Jest tam takie mądre zdanie:

In terms of where most JavaScript MVC frameworks detract from what is conventionally considered "MVC" however, it is with controllers. The reasons for this vary, but in my honest opinion it is that framework authors initially look at the server-side