Pull to refresh

Comments 18

класс! пусть после этого только попробуют поныть на тему отсутствия IT-направленного материала на Хабре!
автору спасибо и респект за перевод
Спасибо за перевод, действительно использование неймспейсов сводит к минимуму воздействия различных библиотек между собой.
> Ext.namespace создаст объекты с переданными именами, если они еще не существуют

> Определение MySingleton внутри пакета App.data

А если объекты существуют, да еще и, например, внутри "пакета" App.data уже есть св-во MySingleton, тогда что?
Нет, все-же в отсутствие необходимых инструментов для органиции подобных структур (namespaces и т.п.) хочешь или не хочешь, а "подглядывать" в чужие скрипты придется для того, чтобы создавать уникальные идентификаторы.
Там есть возможность вложеных нейм спейсов к примеру не знаю как на ExtJS но вот на YUI можно создать чтото вроде YAHOO.my.name.space и я уверен что уже свойство не потеряетса а вообще неймспейсы должны зависить в первую очередь от логики какая реализуетса
в java это реализовано идеально.
ru.habrahabr.core.CoolClass
Я, видимо, напрасно перевел название статьи дословно. Наверное, следовало добавить "отсебятину" в виде уточнения, что уклон статьи - Ext JS. Исходя из этого мне не совсем понятен смысл Вашей мысли на счет "в отсутствие необходимых инструментов для органиции подобных структур".

Что касается вопроса на счет попытки создание уже существующих объектов (рассматриваемый в статье метод проигнорирует такую попытку), то, разумеется, следует выбирать в качестве имен нечто о чем говорит чуть ниже посмотреть профиль monsterzz - уникальное с точки зрения приложения. Если использовать могущие прийти в голову многим разработчикам имена, то ,конечно, будет эффект "от чего ушли к тому и вернулись" хоть с каким алгоритмом организации неймспейсов.

Подводя итог, мыслю в следующем ключе - согласен со всем Вами сказанным, но ощущаю какой-то выраженный протест. Я где-то чего-то не так понимаю? :)
>…ощущаю какой-то выраженный протест. Я где-то чего-то не так понимаю? :)

Ваши ощущения Вас обманывают. Не воспринимайте комментарии лично (это на будущее). Пусть они будут для Вас той благодатной почвой, на которой могут появиться новые мысли или нечно подобное (в смысле, полезное).

>…мне не совсем понятен смысл Вашей мысли…
>…следовало добавить "отсебятину" в виде уточнения, что уклон статьи - Ext JS.

Да, точно – так и надо было. Я-то все воспринял в контексте: "большинство web-приложений состоят из большого числа библиотек, виджетов и сниппетов из многих и многих источников" (со всеми "вытекающими").
UFO just landed and posted this here
по моему, гораздо удобнее использовать конструкции типа:

var App = {

form : {
foo : function () {
}
},

data : {
},

qux : function () {
}

}


p.s.: как-то странно хабр работает с тегом <code>
В частном случае, пожалуй. А вот например, разрабатываете вы свой набор компонент для... для чего угодно. В каждом из скриптов, в самом начале, Вы устанавливаете некий неймспейс, предположим shutnikCmps.nameOfComponent т.к. области видимости кода компонентов также следует разделять. Такой фрагмен, который Вы привели, использовать уже не получится - второй и все последующие из включаемых компонент будут перезаписывать shutnikCmps. Т.о. сначала надо проверять существование верхних уровней пространств. Нет? Или хабр сильно что-то поел и я отвечаю не по существу?
я тож немного поупражнялся :)

function package(p){
var objs=p.split('.');
var cobj=(window[objs[0]]=window[objs[0]]||{});
for(var i=1,l=objs.length; i<l ;i++)
cobj=(cobj[objs[i]]=cobj[objs[i]]||{});
}
package("my.pack.age");
//console.dir(my);
my.pack.age.func=function(){
alert('hi');
};
my.pack.age.func();
Если не хотите привязываться к какому-то фреймворку, для реализации пространства имен можно написать нечто вроде этого:

var someRootNamespace = new Object();

someRootNamespace.provide = function(object_name)
{
var objects = object_name.split('.');

var object = window;
for (var i=0; iЕсли не хотите привязываться к какому-то фреймворку, для реализации пространства имен можно написать нечто вроде этого:

var someRootNamespace = new Object();

someRootNamespace.provide = function(object_name)
{
var objects = object_name.split('.');

var object = window;
for (var i=0; i<objects.length; i++) {

if (0 == i && !window[objects[i]])
window[objects[i]] = new Object();
else if (0 < i && !object[objects[i]])
object[objects[i]] = new Object();

object = object[objects[i]];
}
}


После выполнения данных строк, в любом месте js-файлов можно писать
someRootNamespace.provide('SomeCompany.SomeBigNamespace.SomeBigSubnamespace');
Что-то хабр запорол всё
Использую не только во избежание конфликтов, но и для разделения функций инициализации скрипта. Сейчас пользуюсь схемой — namespace на страницу + один для общих функций.

Все это сложено в один файл + на каждой странице iniline скрипт содержания active_namespace = "Home". Т.е. по DOMReady будет вызвана Home.init()
А в идеале вообще никаких переменных не надо: создали обработчики, повесили их на DOM и всё.
Наверное, возможно, лично я если честно, не пробовал :). Вопрос возникает в самом начале: стоит ли? А как у Вас с этим дело?
Иногда это невозможно, согласен. Но в моей практике в большинстве случаев скрипт просто должен что-то на странице найти, изменить, добавить event handlers и всё. Такой скрипт не должен использовать global scope вообще.
Вот мне хороший урок на будущее. Судя по всему, Вы уже второй человек, которого я непреднамеренно ввел в заблуждение (см. выше) с названием топика. Просто специфика Ext JS, должно быть Вы в курсе, это обычно большие объемы не самого простого кода. Т.е. не описываемый Вами случай.
Sign up to leave a comment.

Articles

Change theme settings