All streams
Search
Write a publication
Pull to refresh
34
0
Тимофей Яценко @thekip

User

Send message
Спасибо, исправил. Просто часть скопировал с IDE с реального проекта, а другую часть дописывал в текстовом редакторе без подсветки, вот и получилась каша.
Мне тоже не понравилось что только строкой, анонимная функция смотрелась бы куда лучше. И так же пришлось шерстить документацию что бы понять можно ли её туда передать или нет.

Но я подозреваю что разработчики не планировали что люди будут вручную составлять этот файл, предполагается что ты генерируешь его через какой либо ГУИ, а там только строками.
А как насчет спикеров на другие тематики? Состав уже набран?
К примеру сейчас перестали гнаться за количеством цветов в дисплеях. А ведь раньше это было весьма актуально. Так и сейчас, дойдут до практического максимума или максимума полезности и перестанут… углубятся в количество ядер процессора )
Начало видео напоминает шедевры современного искусства и авторского кино.
А это вообще нормальная практика брать деньги за вход на подобные мероприятия? Мне всегда казалось что здесь все должно быть наоборот, чем больше людей туда попадает и увидит новые продукты, презентации и т.п. тем эффективнее получится реклама.

А за такие суммы, какие хотят за вход, я, простой обыватель, вряд ли бы захотел туда идти… Какой в этом смысл?
Да, этот метод снимает часть проблемы связанной с длинной строкой вызова метода, но не решает главной проблемы — отсутсвия полиморфизма.
Т.е. Один раз написав код который использует методы родительского объекта я не смогу потом подменить их реализацию в дочерних объектах не изменив по всему коду ссылки.
Что мне не нравится в фабрике виджетов jQueryUI так это то что я не могу обратиться быстро и удобно к родительскому методу, если таковой не определен в конкретном виджете…

Т.е. если я отнаследовался от какого либо другого виджета, и если я хочу вызвать его метод, я не могу написать this.someParentMerhod(), приложение ругнется что его не существует, вместо этого мне придется прописать всю цепочку вложенности от jQuery до прототипа родительского виджета…
Сами минусов вам не ставил, но могу предположить что вам их ставят потому что статья довольно слабая и есть огрехи по теоретической части.

Например в самом начале:

Плагин в jQuery — это обертка над элементом

WTF? Плагин в jQuery это функция которая добавляется в прототип jQuery, и может вообще никак не взаимодействовать с элементом.

И так огрехов в статье достаточно.

От себя могу посоветовать следующее. События — это однозначно хорошо. Система построенная на событиях гораздо гибче таковых на прямых вызовах. Вы идете в верном направлении. Однако стоит еще немного изучить теории и best-practice по созданию плагинов и вообще по Javascript. Например что ваши события желательно вызывать с неймспесом (например triggerHandler('click.myPlugin');)

Касаемо jQueryUI — Безусловно фабрика виджетов JqueryUI хороша, помогает избавиться от многих рутинных вещей, таких как сеттеры/геттеры для опций, или вызов методов если передан не объект а строка и т.п. Но иногда это все не нужно, и хочется сделать плагин с минимальным количеством зависимостей. И в этих случаях я лучше напишу без фабрики JQuery.

А вообще в последнее время я начал писать плагины способ несколько иным чем рекомендует документация jQuery, а именно, я в начале описываю конструктор объекта, затем добавляю в прототип методы, а затем уже заворачиваю это дело в плагин jQuery.

Пример:
   /**
	* Конструктор плагина Multiinput
    * @param {HTMLElement} element - container of multiinput
    * @param {options} options object passed from jquery adapter
    **/
    function MultiInput(element, options){
        var $this = this;
        this.ancestor = $(element);
        this.options = options;
	}
	
	/*Добавляем к конструктору необходимые методы*/
   MultiInput.prototype = {
        /**
        * trigger plugin event
		* Моя реализация событий в плагинах. Я вызываю данный метод, который одновременно вызывает и 
		* коллбэк функцию указанную в опциях и поджигает событие с помощью triggerHandler()
        * @param {string} event  - event name for triggering
        * @param {object} context - ('this' for event handler) this param will be passed to 'call()' function
        * @param {array|object} params - custom arguments for handler
        **/
        triggerEvent: function(event, context, params){
            if(!(params instanceof Array)) {
                params = [params];
            }
       
            this.ancestor.triggerHandler(event, params);
            this.options[event].apply(context, params);
        },
        
        /**Остальные методы плагина**/
        
	}
	
/**
 * jQuery plugin
 * @param {options} options
 **/
$.fn.multiInput = function(options){
    var options = jQuery.extend({
		//some default options
    }, options)
    return this.each(function() {
		//Для каждого найденного элемента создаем свой экземпляр плагина, передаем в него свой экземпляр настроек, и таким образом решаем проблемы "изоляции областей видимости переменных".
		//Кроме того, экземпляр плагина хранится непосредственно в DOM объекте, и 
		//добавив несколько дополнительных условий в данный конструктор можно реализовать функции get/set и вызов методов для каждого экземпляра прикрепленного к элементу
        $(this).data('multiinput',  new MultiInput(this, options));
    });
}


Если кому интересно я могу написать статью в котором выложу аккумулированные знания из разных статей из хабра по лучшим практикам в ООП, и по практикам создания плагинов и событий к ним (все это уже есть на хабре, но в разных статьях и с разными акцентами)
Есть еще одно элегантное решение без создания robots.php

RewriteRule ^robots.txt$ robots.txt.%{HTTP_HOST} #направляем на разных доменах на разные файлы robots.txt


Соответственно в в корне сайта кладем два файла robots, для каждого домена и прописываем там свои независимые правила.
Способ удобен тем, что горе-оптимизаторы не набыдлокодят своей логики. Только прежде нужно предупредить их о том что для каждого домена запрашивается свой роботс.
Спасибо за интересную статью! При чтении возник один вопрос, как устроено ваше АПИ? А именно как устроена передача объектов (данных) из нижних уровней, в верхние?
На сегодняшний день приложения на Yii чаще всего оперируют объектами ActiveRecords, как объектами предметной области. В данной слоистой архитектуре мы должны абстрагироваться от моделей, и инкапсулировать их в расширения. Т.е. мы не можем передавать их вверх другим слоям.
Значит необходимо создать некую коллекцию классов описывающих объекты предметной которая будет являться частью АПИ, и будет неизменна вне зависимости от реализации расширения.
Для вашего примера с UserExstentionAPI необходимо как минимум создать класс User, который после успешной авторизации будет передаваться вверх модулям-пользователям расширения.

Если я все правильно понимаю, то такой подход может значительно увеличить количество работы, и кода к примеру:
описали модели внутри модуля, реализовали бизнес логику, написали АПИ которое состоит из методов и нескольких классов (объектов данных), которые приблизительно повторяют модели, но ими не являются.

Так вот вопрос, как реализовано это у вас?
Что мешает в настройках аккаунта запретить распознавания его лица на чужих фотках? Т.е. глобальная настройка, а не подтверждение уже распознанной фотки. Т.е. если я хочу что бы меня распознавало на чужик фотках, поставил галочку, мои биометрические данные попали в БД по которой работает распозновалка, и вуаля — я сам разрешил поиск.
Вы давно не пользовались Firefox с фаербагом…
Снимаю часть своего вопроса: setTimeout нашел в вашем Api.
Но вот как реализован JS все равно интересно. Я так понимаю что задействован Windows Host Script, но я попытался использовать его встроенные объекты и у меня ничего не вышло.
Я не слишком силен в этой специфике, основное направление разработки всегда было WEB…
Заинтересовал плагин. В процессе написания своего JS плагина под ваше решение столкнулся с некоторыми трудностями:

Поскольку работает мы уже не в браузере, и вместо стандартного браузерного объекта window, у нас объект Editor, то где искать методы типа setInterval, SetTimout?

И вообще интересует каким образом сделан этот плагин, в плане движка, вряд ли в плагине реализован собственный движок, ведь так?
Я спрашиваю это для того что обратиться к его мануалам и посмотреть какое АПИ доступно кроме описанного вами.
В плохо спроектированных ООП системах — сплошь и рядом.

К примеру есть некий контроллер NewsController, есть вроде как даже модель NewsModel (правда в не совсем верном её понимании).

У модели есть метод: NewsModel->getAllNews(), при вызове которого, а возвращается какой то массив, с этим массивом дальше начинают работать в контроллере, всячески его обрабатывая, и в конце концов выводя в браузер.

Таким образом вся архитектура построенная на массивах, которые гоняют туда-сюда.

Добавил предупреждение. Теперь должна быть понятнее суть предложения.
Вы видимо прочитали только заголовки в статье.
Если бы в рассмотрели пример, и вникнули в суть, то поняли, я не предлагаю заменить ВСЕ массивы.

Массивы — это удобный инструмент, и должен использоваться по своему прямому назначению, а именно:

Массив — упорядоченный набор данных, для хранения данных одного типа, идентифицируемых с помощью одного или нескольких индексов.

(вики)

И в этих случаях они и должны быть использованы.

Я говорил о тех случаях когда массивы используются как основную структуры данных, когда массив становится центром всей системы, и вся бизнес логику начинает вращаться вокруг него.
Статические HTML странички отдаются еще быстрее, но ведь никто не стремится делать сайты на одном только HTML?

Нам всегда нужно выбирать между удобством разработки и эффективностью наших программ.

К примеру, тот же ActiveRecord: все знают что он медленнее чем просто запрос-ответ, но так же никто не собирается с него уходить, все понимают какие плюсы он несет. Скорость и удобство разработки, не сопоставимо с теми тормозами которые могу возникнуть.
Все верно, такая структура позволит вам быть чуть более уверенным в том что нигде ничего не поломается со временем, и уверенным в том, что в любой момент вы сможете добавить некую бизнес логику в сеттер поля Name.

Часто «быстрые» решения не всегда полезные. Иногда приходится тратить несколько часов на рефакторинг определенного кода, хотя это можно за 2 минуты решить с помощью копипаста одной функции в несколько мест. Цена этого решения всплывет потом, и смею вас уверить будет гораздо дороже чем изначально придерживаться принципов заложенных архитектурой.

Information

Rating
Does not participate
Location
Краснодар, Краснодарский край, Россия
Date of birth
Registered
Activity