Apr 18

Prototype element storage api

Javascript, Learn, Prototype , , , Добави коментар

Наскоро (преди около месец де) излезе Prototype 1.6.1 RC1, основната цел на тази версия е съвместимост с ново излезлият IE8, и Element.Store ( за който бях писал преди време ).

Toчно за  Element.Store исках да драсна някои ред, защото изненадващо за този тип storage няма много материали в нет-а.

Основната идея на Element.Store е да може да се добавя информация (като обекти) към даден  елемент, без да се страхуваме от memory leaks. Това в Prototype е реализирано със следните методи (под $(element) имам предвид референция към prototype extend element):

  • $(element).getStorage() – директен достъп до Storage-а на даденият елемент,  той просто представлява един Hash в който се запазват всички обекти, които искаме да прикачим към елемента. Дефакто store/retrive се явяват shortcut-и на get/set методите на този Hash.
  • $(element).store(key, value) – записва информация в даденият елемент, ключът трябва да е string (или обект с метод toString), после когато искаме да си вземем информацията отново използваме ключа. Възможно е наведнъж да се запишат повече от една двойка ключ – стойност: $(element).store({ key1: ‘value1′, key2: ‘value2′ /* и така на татък */});
  • $(element).retrieve(key, defaultValue) – извлича информация от елемента по даден ключ, като ако не съществува такъв ключ се връща  defaultValue.
  • вероятно $(element).unsetStorage() (ticket | gist) – този метод все още го няма, но е много вероятно да се появи във финалната 1.6.1 версия, той трябва да премахва цялата информация за дадения обект от Storage-a му. Ако искате в момента да ползвате unsetStorage може да вземете моята примерна версия от тук.

Как обаче това би се ползвало в реалния свят ? Първо най-вероятно във финалната версия 1.6.1 цялата event система на Prototype ще използва Element.Store. А аз ще си позволя да дам един малък пример за това как и къде се ползва Element.Store:

Имаме примерно масив с футболисти на Арсенал, и на страницата имаме бутони, чийто id-та се образуват от ‘button_’ + номера на футболиста. Целта е при натискане на бутон за даден футболист да се показва името му с alert.

var footballers = [
	{number: 14, firstName: 'Theo',     lastName: 'Walcott'},
	{number: 12, firstName: 'Carlos',   lastName: 'Vela'},
	{number: 23, firstName: 'Andrei',   lastName: 'Arshavin'},
	{number: 4,  firstName: 'Francesc', lastName: 'Fabregas'},
	{number: 5,  firstName: 'Kolo',     lastName: 'Toure'},
	{number: 25, firstName: 'Emmanuel', lastName: 'Adebayor'}
];

Общо взето без имаме 4 възможни варианта:

// Вариант 1: използваме closure за достъп до футболиста
footballers.each(function(f){
	$('button_' + f.number).observe('click', function(){
		alert('#' + f.number + ' ' + f.firstName + ' ' . f.lastName);
	});
});

// Вариант 2: използване на скит closure
function show(f){
	alert('#' + f.number + ' ' + f.firstName + ' ' . f.lastName);
}

footballers.each(function(f){
	$('button_' + f.number).observe('click', show.curry(f));
});

// Вариант 3: използване на референция в самия обект
function show(){
	var f = this.footballer;
	alert('#' + f.number + ' ' + f.firstName + ' ' . f.lastName);
}

footballers.each(function(f){
	var button = $('button_' + f.number);
	button.footballer = f;
	button.observe('click', show);
});

// Вариант 4: използване на Element.Store
function show(f){
	var f = this.retrieve('footballer');
	alert('#' + f.number + ' ' + f.firstName + ' ' . f.lastName);
}

footballers.each(function(f){
	$('button_' + f.number).store('footballer', f).observe('click', show);
});

Всички варианти работят и правят едно и също (или поне така си мисля :) ), но всеки си има и своите особености. Така Вариант 1 изглежда добър вариант и също така е доста се използва именно този метод, но това което ме притеснява е че анонимната функция към бутона се пре-декларира за всеки бутон (въпреки, че това пак зависи от интерпретатора). Също така при по сложни скриптове може да се получат обърквания кое от къде идва и на къде отива, а и от самия код не е много “чист”. Във Вариант 2 се използва curry, което прави кода малко по-чист, но въпреки, че не е веднага видимо пак се използва closure ( в curry метода ) и отново има генериране на доста анонимни функции.  Вариант 3 променя още структурата кода, като се маха curry, и се добавя референция към футболиста в самия обект, така не се генерират множество функции, но вероятността да се появят memory leak-ове е много голяма ( а и самия код изглежда най-зле от всички варианти ). За мен лично вариант 4 е най-удачния (особено при по-големи проекти), сега към обекта пак се записва референция към дадения футболист, но този път се използва безопасния Element.store .

Надявам се с този малък пример да съм показал част от възможностите който предоставя новия Element.Store механизъм и защо е полезен той :)

В заключения ще дам за пример с CD3.Select класа ми, който се използва за правенето на custom html select контроли. Като просто като се напише new CD3.Select(selectElement), автоматично selectElement-а се замества с група от div/ul/li елементи и така се дава възможност на дизайнерите ни в Pixeldepo, да ги настройват както намерят за добре (всъщност в моите ControlDepo 3 Widgets имам още цял арсенал от компоненти, с подобни функции). Та преди в CD3.Select за капсулирането на връзката между options обектите и техните производни li елементи използвах closure, като след появата на Element.Store промених нещата. При което се забелязах че доста по-добре и глатко  работят самите контроли и много по-малко памет се използва :)

Element.Store използвам още за Event.deletege, който много се надявам да попадне в core-a на Prototype.js и за който в следващата седмица мисля да напиша един пост.

Какво мислите по въпроса