- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
var htmlContent = "<li class='savedAdItem' data-savedid='" +
adToAdd.cid + "' title='" +
Company.i18n("ads_manager.ClickToSeeDestination") +
(adToAdd.get("title") ? adToAdd.get("title") :
adToAdd.get("url")) +
"' data-url='" + adToAdd.get("url") +
"' ><div class='title landing'>" +
(adToAdd.get("title") ? adToAdd.get("title") : "URL") +
"</div><div class='landingUrl hide'>" +
this.getDomainName(adToAdd.get("url")) + "</div>" +
(adToAdd.get("imageUrl") ?
"<div style='text-align:center;'><img src='" +
adToAdd.get("imageUrl") +
"' style='max-width: 99px;max-height: 72px;' /></div>" :
"<div class='img-target-" + adToAdd.get("targetType") +
"'> </div>") +
"<div class='btnDelete' title='" +
Company.i18n("ads_manager.Remove") +
"'></div></li>";
Follow us!
Для полного счастья не хватает только js кода внутри этой строки.
На сейчас я заменил чем-то вроде этого:
Но не факт, что оно так останется, скорее всего это уйдет в какой-нибудь шаблон.
тот же инлайн, но с извратами.
От того, чтобы динамически создавать ХТМЛ элементы все равно никуда не уйти, но так хоть есть возможность держать данные об этих ХТМЛ элементах в таком виде, в котором с ними можно нормально работать в ж.скрипте.
К сожалению то, как ДОМ представлен в ж.скрипте не оставляет особо выбора.
Куда уж более читаемо? В коде функция в одну строчку, которая складывает строки в массив и потом их джоинит. Если человек это не осилил, то лучше пусть идет на фабрику коробочки складывать.
"я поебался, чтобы это написать, теперь ты поебись, чтобы это прочитать"
как перебор свойств какого-то объекта должно приводить as is к html тегам? или ты собрался на клиент засылать тот же html, только в json? типа всех наебал, сэкономил трафик, так чтоли?
Зачем столько агрессии? Он всего лишь запилил простенький конвертер js->html (ну да, тут не хватает правильной экранировки, и, в идеале, рекурсии, но не суть, это все дело техники), чтобы не конкатенировать хтмл врукопашную:
его должен сервер отдать?
замечу, что в ОП объект используется сложнее, с кишками
повтори-ка целиком (увидишь кучу повторений обращений к "свойствам" объекта)
сервер не должен в модели передавать, что это div, какой у него обязан быть класс и т.д.
нужны сухие данные
желательно, с осознанным Типом этой сущности (а не 'div'), да так, чтобы на html вообще ничего не намекало
Это не json, это код на js :) Его напишет wvxvw в качестве эдакого шаблона. А сервер передаст чистые данные, которые в этот шаблон подставятся (сейчас они лежат в adToAdd.get('title') и им подобных).
Ну просто шаблон вместо традиционного html со всякими {{prop}} или ${prop} записывается прям в виде кода на js.
О как, не знал про эту штуку. А дальше append'ом запихивать их друг в друга? Довольно удобно.
нездорово мешать разметку и js
место разметке - в .html
правильно будет:
Но не суть. Что да важно, и что показательно, что:
1. С объектом проще работать, чем с методами ж.квери, потому что есть, например подчерк.
Что, вобщем, сделало бы код менее "китайским".
2. Как я уже говорил, эти объекты создавать нужно все равно. И поэтому лучшим вариантом будет:
3. Самое главное, что код, из которого мы смогли убрать конкретику "title", "url" и т.п. можно вынести в библиотеку и использовать повторно. Но рабы дефекейт++ не будут искать легких путей, когда "url" заменят на "href", они просто скопируют старый код и немного его подправят:
Как говорит Дан Денет, "Если работу можно не делать вообще, то ее можно сделать как угодно хуево".
вот примерно этот вариант я и имел ввиду
Может не рабочее, но принцип должен быть ясен.
Почему бы не подставлять поля из объектов "модели" в шаблон, не переписывая их в промежуточную сущность?
Вот у него есть такая модель окружающего мира:
Таким образом, если мы захотим потом этот же компонент использовать как селект, а не лист, мы от него унаследуемся и заменим renderer: Li на Option.
А там разве нельзя у компонента сделать несколько представлений? Даже в сраной джумле можно было ;)
> этот же компонент использовать как селект, а не лист, мы от него унаследуемся
Наследование ради реализации приводит к длительным запоям.
Ну и что-то я не пойму, зачем все эти map, makeListItem, рукопашное создание нод и т.п. В подчеркивании шаблонизатор настолько уныл, что в нем нельзя описать циклы?
Так работает ГТК, Винформс, Флекс или Свинг, но вот в ж.скрипте до этого еще не доросли.
И когда нужно будет решать эти проблемы, а они неизбежно возникнут, только не на первом этапе работы, а после нескольких месяцев / лет, когда менять уже будет сильно влом, и врезультате будут появляется решения, типа как в ОП.
...задуматься на мгновение, что же объединяет все эти "компоненты"?
А общее в них только то, что они отображают некий элемент коллекции в кусок DOM'а. А это... банальнейший репитер, который уже есть в любом шаблонизаторе.
А может мне нужно пойти дальше, и разработать "базовый класс" для "компонента", который умеет рендерить или не рендерить свое содержимое в зависимости от какого-то предиката? :)
А может мне нужно забить на написание "компонентов" для for'ов и if'ов, воспользовавшись вместо этого готовыми инструментами, и сразу делать компоненты, имеющие какой-то прикладной смысл...
Для создания гуй приложений не только шаблонизатор, язык разметки - верх кретинизма. Мне довелось поработать в среде, где можно было пользоваться и тем и другим в более-менее сравнимой степени: MXML / AS. Код с использованием MXML пишется быстрее, и это плюс, но хорошо написаный AS код будет всегда короче MXML, будет более универсальным, легче при поддержке. Кроме того, MXML гораздо больший язык, чем ХТМЛ, т.е. в нем есть на много больше разных возможностей / настроек компонентов, и тем не менее, настройка компонентов в AS проще и более универсальна, чем ее когда-либо можно было сделать в MXML. ХТМЛ по сравнению: детский лепет, на дворе 2014 год, а ж.скрипт обезьяна не сможет даже скроллбар раскрасить в нужный цвет.
Базовый класс для компонента разрабатывать не нужно, он уже есть в Бикбоуне. Просто ни одна обезьяна еще не догадалась, что вместо того, чтобы наследоваться от этого класса и потом в каждом наследнике повторно реализовывать похожие компоненты, их можно было реализовать один раз, а потом наследоваться от наследника.
Ж.скрипт морально очень напоминает Флеш 2004-го года, тогда только появились классы, и типичная программа сводилась к множеству классов, все унаследованые от MovieClip. Понимание того, что можно унаследоваться от наследника пришло после знакомства с ASWing, но это было относительной редкостью. До 3-его Флекса иерархии наследования, как правило были одноярусными.
Бикбоун, в свою очередь, очень сильно напоминает модель компонентов flash.mx.* из пре-2004 серии, по крайней мере грабли там они насобирали очень похожие.
Нет, и еще раз нет, это уебищный путь, который добавляет работы в геометрической прогресси. Это антитезис компонентной архитектуры, который мешает использовать код повторно. Ну не нужны мне уже готовые строки-куски ХТМЛ, не нужны. Мне их нужно создавать исходя из модели компонента. Иначе, вместо повторного использования компонента я получаю дохера "китайского" повторяющегося кода.
Естесственно, ни один ж.скрипт писатель не думает о модульности, компонентой архитектуре, или элементарно о том, как себе сократить объем работ, поэтому каждая модель описывается декларативно, а потом циклами со свитчами и ручной поклейкой строк из нее производится "представление".
Так получается "китайский" код, повторяющийся с небольшими изменениями от страницы к странице (а иногда и много раз в пределах одной страницы).
Переводить это унылое говно очень нетворческая задача, т.как нужно каждый раз выискивать места поклейки строк и в них искать недопереводы. Недопереводы в такой ситуации имеют тенденцию повторятся, как и все остальное.
Чтобы как-то скрасить будни, я решил вынести все повторяющееся говно в один компонент, а говно уникальное для каждого инстанса этого компонента как-то задавать снаружи. Объекты в этом смысле хороши еще и тем, что их ж.скрипт может нативно расширять, т.е. если у меня ест 100 инстансов схемы требующих слепить список из { "": "a", "href": "http://localhost" }, и еще десяток { "": "a", "href": "http://localhost", "alt": "Home sweet home!" }, то во втором случае я смогу применить наследование для того, чтобы избавить меня от непосильного труда набивания этой херни!
Кроме того, я смогу использовать ОО механизмы, типа методов для работы с такими моделями! (для того, чтобы заменить портянки из свитчей).
Вобщем, профит есть.
ССЗБ, или я не прав? :)
модель осталась прежняя, представление изменилось
модель сгружается динамически из базы, представление - статический текстовый файл
ибо модель - всего лишь items, все остальное - шелуха, которой не место в js
эту срань надо описывать в разметке
если что у тебя будет отличаться одним тегом, ты это сможешь сделать и в шаблоне
но если хочется получить сайт, в котором не будет никакой возможности найти хоть каких-нибудь концов, что именно получается и где - т.е. сайт, в котором будешь разбираться только ты, то после твоего ухода проект рано или поздно просто отправится в мусорку и будет переписан с нуля
кто вообще додумался дать в руки человеку проект, который ненавидит инструмент, на котором он его делает
Контрол который должен показывать дни недели присутсвует на более-менее сотне страницах системы. В нем есть несколько нужных различий, типа стиля, выделения, возможности редактирования и т.п. + дохера случайных изменений, сделаный изза невнимательности долбоеба-ж.скриптера при копирование и вклейке. Таким образом моя работа из чего-то типа:
Превратилась в составление регулярок. При чем нужно искать не только по ХТМЛ шаблонам, но и по ж.скрипт коду, где потом эти шаблоны наполняются данными. Почему? Потому, что по совету какого-то надразума компоненты создаются посредством парсинга ХТМЛ-подобного текста, вместо того, чтобы держать их представление в виде ж.скрипт объектов.
Кто додумался? Ну, не смотря на то, что я его не люблю, я все равно это делаю лучше любого ж.скриптера, который его любит. Работодателю-то какая разница?
если второе и предыдущий программист расклонировал 100 раз, то всяко он мудак, это не зависит от языка, был ли это джаваскрипт или прости господи флеш
парсинг html подобного текста хорош тем, что 1) легко читается и сопровождается, 2) легко распределяется между front-end разработчиком и верстальщиком, 3) легко меняется на абсолютно другой, для других устройств и т.д., притом, что это будет работа для специалиста по этому направлению - верстальщика, а не специалиста в js
просто если твой нынешний шаблонизатор заставляет вставлять html-подобную хуиту прямо в js с кучей инородных знаков, то нахер его
да и вообще это крайне странно, что в одном проекте данные одной модели пытаются отформатировать в сотне различных представлений по-разному, это уже очень и очень попахивает
ХТМЛ - по своей сути идиотская задумка, и единственное оправдание существованию шаблонов в виде фрагментов ХТМЛя заключается в том, что блядские браузеры быстрее парсят и сами создают ДОМ структуру, чем если напрямую обращаться к ДОМ АПИ (такой вот ебический АПИ).
Шаблоны утыканые инородными языками с кучей экранирования и дополнительной пунктуации для разделения ХТМЛ и не-ХТМЛ кода хорошо читаются? Возможно только для тех, кому нравится читать суржик смешаный из трех с половиной недоязыков. Почему кому-то вообще приходит в голову мысль аппелировать к чему-то на столько тяжело объективно характеризируемому, как "удобство чтения"? Да, в этой области есть исследования, но естесственно, никто не проводил экспериментов сравнивающих методически удобство чтения исключительно ж.скрипт кода по сравнению с чтением месива из ж.скрипта, шаблонизатора, ХТМЛя и КССа - с чего вдруг это подается под видом фактов?
Нет ничего странного в том, что данные модели компонента нужно по-разному форматировать в зависимости от контекста. Вы это видите в любой гуй-программе по сто раз в день. В одном месте у кнопки есть рамочка, а в другом - нет, где-то у селекта ест возможность выбрать несколько элементов, а где-то - только один и т.п.
Единственное, что, если это происходит в ХТМЛе, то можно быть на 99% увереным, что мудак-ж.скриптер написал две разные кнопки, одну с рамочкой, а другую - без, создав их из двух разных шаблонов. Потому что абстракция - это думать нужно, копипаста - проще.
Окай. Вот идеальный код, с этой точки зрения:Вечен как скала - никому и никогда не придется менять его при сопровождении.
Гибок как ивовый прутик - достаточно поменять "данные", чтобы получить любое поведение.
p/s
FindFirstFile/FindNextFile
Причем они тут?
читай про обедующих философов
Дас кен ихь шон.
Причем они тут? На философах рассматривают дедлоки. А боты стертора будут писать посты бесконечно, пока сайт не завалится. Это совсем разные проблемы.
Ханойские монахи будут перекладывать диски бесконечно, пока мир не развалится.
- А давай придумаем Оптимальный Алгоритм, по которому мы сможем их переложить за 2^n ходов?
- Некогда думать, надо диски перекладывать...
Тонко.
Я о том, что если у компонентов проблема из-за несогласованности - нужен контроллер. По этому принципу я их с философами и соединил
Философам не нужен помощник. Там же один из способов - тупо пронумеровать ресурсы, и начинать с меньшего номера.
Или тупо игнорить при распознании.
Самое явное решение философов - официант. Ибо гибкость.
И далеко не самое удачное, т.к. добавляет единую точку отказа. Заболел официант - все 5 философов зависли и сдохли с голода.
Основной + супервизора - гибкость управления
Эрланга начитался? :)
P.S. А вообще официант - пидорас. Мог бы просто принести им еще 5 вилок.
Кстати. Отвлекаясь. Поставил я LinuxMint, у меня от нее постоянные стояки. А как там, что? как ставить приложения? В яндексе полый бред.
Можно apt-get install [имя пакета]
а че mint то ? ставил бы как все ubuntu)
Внезапно, но мята и есть убунта.
не чистая, не тру
т.е. выбираем в папке "открыть с админскими правами", запускаем apt-get install [имя пакета] в консолечке? Фи, какая гадость... Но от этого никуда не деться.
sudo rm -rf /
работает на 20% быстрее
Не работает же, уже давно.
а я и забыл стертор
sudo rm -rf --no-preserve-root /
без --no-preserve-root опасно! еще систему себе снесешь из-за меня!
Что-то я не заметил выйгрыша в скорости.
В винде - да, было.
Я х.з. есть ли он в минте, но все-таки поищи там Центр Приложений :)
sudo apt-get install software-center
не нормально
внимательно почитал то, что тебе написали при попытке установки?
виртуалбокс при установке дополнений тоже желает кернел сурсес (они, кстати, скачиваются тупо из центра приложений по имени linux-sources или вроде того), но это не обязательная ему вещь
как бесплатность программы показывает ее функциональное превосходство?
для домашнего использования поиграться в линукс на виртуалке у вмвари вообще нет никаких преимуществ
у виртуалбокса возможны тормоза с пробросом 3д-ускорения, но оно в линуксе нахер не вперлось - последнее дело оценивать играбельность шутера, запущенного из виртуалки
в остальном не вижу нахуя ставить вмварю, крячить её, если можно поставить бесплатное полнофункциональное приложение с официального сайта
Ничего в ней не изменилось - абсолютно.
причем с рабочими нуждами
с различными системами
ни разу не тормозил или вис
ЧЯДНТ?
Вот сколько лет юзаю виртуалбокс, никогда такого не было. Поди вырубал машину во время этого слияния?
> Можно также сжимать неиспользуемое пространство "резиновых дисков", дефрагментировать их.
Ну вот этого в виртуалбоксе нету, да.
> виртуалбокс тормозит и виснит в отличии от вмвари
Да ну?
У тебя мало опыта. Я пока не юзал ХР, тоже думал что 98ая стабильно работает. Я понял что твоё восклицание означает. Я говорю очевидные вещи.
поставил Wine
Дельфы на линуксе
Tform1.formcreate()
Я дрочу от счастья - любимые окошки всегда со мноооооой
Windows 98 с хостовой стороны что-ли?
На XP он нормально работает. А внутрь ему я пихал и дос и вин3.1, все нормально было...
Можно подумать в тех ОС экранчики были намного больше ;)
device=mouse.sys
Записал его в autoexec.bat
>>что ты в линуксе будешь делать то?
Да хз, что. Может, плюнуть на гордость и поставить ее в качестве основной ос? Что посоветуете, товарищи?!
у меня с ним негативный опыт
поебался не больше пары часов, и т.к. был цейтнот, просто снёс его и поставил другую систему
Размер рабстола регулируется видеодрайвером/драйвером дисплея. При чем тут система?!
И еще 300% проца остаются другим процессам. Мне как-то пох ;) А вообще меня это даже на двухъядерке не особо напрягало. Утилиты ставил, в основном, из-за растягивания окна, общих папок и общего клипборда.
P.S. Да, у меня под столом стоит гроб, ибо я не признаю ноуты из-за уёбищных клавиатур и систем охлаждения.
Шум же и $$ электричество. Гроб может у тебя с супердуперохлаждением, но на ноутах может включиться кулер.
Да один общий курсор мыши без ковыряния с клавишами чего стоит. Графика не тормозит.
Тишина полная. Моник только, сука, пищит. Видимо из-за того, что уже лет 7 ему.
> $$
Ну и насколько оно больше жрет в простое (инет, написание кода) чем твой ноут? Ну раза в два максимум. Замерю завтра, если интересно.
> на ноутах может включиться кулер
Который или воет как самолет или нихуя не охлаждает. А еще он забивается пылью, и ему хер проведешь профилактику.
>А еще он
А еще у меня с ним приключилась какая-то херня и он стал выть как пылесос, то ли смазка закончилась, то ли за корпус задевать стал. Вибрация передавалась на стол, играл с затычками в уши :) Потом пошел в ремонтную, мне сказали, что раз ревет - пошел подшипник по пизде. Посмотрел цены на кулеры для модели и решил попробовать его смазать. Купил густой смазки в строймаге за 3 евро, намазал чуть-чуть на ось - хуяк и стало тихо о_О. Еще за это время, судя по всему, стали появляться беды на винте, комп стал падать в блюскрин при проигрывании громких звуков о_О. Короче, нужен новый комп. Ноут=дрова.
большое кощунство.
>>В каком месте я спорю?
Да ты даже не замечаешь этого, эх.
Так что ничего особенного в этом наблюдении нет. Есть только типичное заблуждение, когда утверждение отвергается на основании нежелаемых последствий результата, а не на основании его фактической правильности.
Да, eval(code) проще поддерживать потому, что от такой программы никто и не требует ничего особенного. Вот только продать такую программу, чтобы потом ее поддерживать будет очень сложно.
Не-а. eval может вернуть любой тип и лови потом ошибки.
Заметь, результат eval'а в этом коде никто не смотрит. Так что не будет ошибок.
(мне все больше и больше нравится J, вот еще немного соберусь с мыслями и напишу интерпретатор на ж.скрипте. Но такая ситуация с J неизбежна не из-за синтаксиса, а из-за того, что, что нужно много додумывать: все время нужно помнить сколько измерений осталось в аргументе, а к скольки применяется слово.)
Лисп, наоборот, относительно многословный язык и за исключением десятка функций не типичных для других языков, больше ничего особо осиливать не нужно, чтобы его понимать.
Сколько трафика сэкономится от замены js на j :) Надо везде внедрять.
p/s/
Сучонок, девчонка, собачонка, книжонка, рубашонка - через "о".
Человеку для хорошего понимания нужен определенный баланс: если очень много информации подразумевается, то смысл начинает терятся изза неоднозначности (пример: чтение поэзии эпохи возрождения - если не знать греческую мифологию и выдающихся деятелей того времени - нихрена не понятно). Если явной информации слишком много, то ее тяжело переварить (пример: программы на ассемблере).
J больше похож на естесственный язык в смысле сколько информации нужно получать из контекста (обычно языки программирования более подробные). Люди, судя по всему справляются со сложностью естесственных языков заучивая большие фрагменты "програм", не всегда отдавая себе отчет о деталях.
Я так думаю, что если практиковаться, то можно так же найти "идиомы" языка, тем не менее это не отменяет сложности, это просто своего рода продвинутое "кеширование".
http://habrahabr.ru/post/201470/
Специально для Люра: больше полезных функций.
Ответ лучше на форум, проще будет отслеживать.
• http://javascript.ru/ajax/cross-origin-2
Своими словами:
1. XMLHttpRequest не умеет отправлять на другой домен. Вообще. В Интернет Эксплорере умеет со страницы, сохранённой на компьютере, отправлять на любой домен.
2. Атрибут src тега script умеет отправлять только GET, но не умеет получать ответ. Ответ получить можно, если сервер возвращает JSONP (т. е. оборачивает данные в pituhFunction({данные}), тогда эту pituhFunction можно определить на своей странице).
3. IFRAME. Мы можем в нём разместить форму с автокликом и отправить даже POST, но получить содержимое фрейма из внешней страницы не получится. Разве что если фотографировать экран.
4. Плагины: Flash, Java, Silverlight по вкусу. Из них можно открыть любое соединение и не только http.
5. Все прочие работающие методы требуют поддержки от другого сайта. Сюда относится передача данных во фрейм через указатель фрагмента URL (#), window.postMessage, XMLHTTPRequest 2 / XDomainRequest. Если другой сайт специально не рассчитывает на то, что кто-то будет передавать данные, то ничего не получится.
Работает для любых доменов, но проблема в том, что максимальный размер значения window.name во всех браузерах разный.
Но кто бы мог подумать, что в случае window.name в качестве бонуса ещё и кроссдоменная протечка...
В приватном просмотре все норм, не выживает.
Неужели так трудно подыскать годных проксей?
никакой анонимности, даже наоборот, можно вляпаться.
А вот в этом и проблема. Хотя, если твое общение с целевым сайтом никак с тобой изначальным не связать, то на доверие выходному узлу как-то насрать.
P.S. Вдруг кому-нибудь пригодится:
http://www.bestukvpn.com/
http://superfreevpn.com/
http://xpdo.net/
http://uk.ufreevpn.com/
При этом не забываем пользоваться этим "любым браузером" только для TOR'а. И не ходить им на обычные сайты.
Кстати, у меня почему-то при установленном WideCap не запускается Eclipse.
Не смотрел ваершарком куда лезет эклипс при старте?
через https, пользуясь системным прокси...
Интересно то, что Эклипс не запускается даже с отключенным WideCap, т. е. WideCap нужно полностью деинсталлировать, тогда запустится. Причём сообщение об ошибке выводит совершенно нелепое.
Защита от взлома? xD
ЧИ-ТА-БЕЛЬ-НО!!!!