Search
Write a publication
Pull to refresh

Comments 7

Сюда смотрели?

Моя специализация верстка, с jq сталкиваюсь очень часто. Тема статьи «Организация разработки веб-приложений с JQuery виджетами», по моему скромному мнению она не раскрыта.

Я делаю так:

1. Подключение требуемых библиотек.
2. Подключение активатора.

Получается примерно так:

<script src=«pub/js/jquery.js»></script>
<script src=«pub/js/jquery.calc.js»></script>
<script src=«pub/js/jquery.slider.js»></script>
<script src=«pub/js/jquery.foto.js»></script>
<script src=«pub/js/jquery.ДОМЕН_САЙТА.js»></script>

Под активатором я понимаю как раз файл jquery.ДОМЕН_САЙТА.js, в нем примерно такой код:

$(function(){

  var $calc = $('.b-calc');
  if ($calc.length) {
    $calc.calc({
      // Опции
    })
  }

  var $slider= $('.b-slider');
  if ($slider.length) {
    $slider.slider({
      // Опции
    })
  }

  var $foto= $('.b-foto');
  if ($foto.length) {
    $foto.foto({
      // Опции
    })
  }

})

Все удобно, все прозрачно.

В активаторе занимаюсь не только активированием плагинов, но и пишу минимальный код, специфичный только для этого сайта, и который жалко оформить в виде отдельного файла.

Не хватает подключения библиотек в активаторе, тогда было бы еще лучше, на всех страницах подключаем 1 файл, в нем в зависимости от html подключаем нужные библиотеки, и активируем их.

Видел на некоторых сайтах, что все библиотеки сливаются в один файл. Когда библиотек не так много, возможно и удобно.

В данном способе нам не нужно думать на какой странице какие файлы подключать.

Кстати, по ссылке, что я дал в самом начале, взаимодействие между библиотеками реализовано вполне нормально.
На вкус и цвет товарищей нет, как говорится.
Я по своей специализации ООП. Так что по моему скромному мнению —
«слить» все в один файл приведет в конечном счете к тому, что счет переменным потеряется и скроллинг по файлу превратится в массаж пальца.
За ссылку огромная благодарность.
Кстати говоря, в моей реализации помимо того что не надо думать где какие файлы подключать, наследованние позволит единожды определить паттерн основных методов и свойств, а в производных методах дорабатывать функционал.
Мне кажется, если бизнес-логика (функционал jq) содержит механизмы запросов( так сказать распределенную логику) и осуществляет обращение к модели через WCF и иные механизмы коммуникации, сложновато будет это держать в одном месте или постоянно копи-пастить
под слить в один файл, подразумевается объединить код плагинов, и конечно, так лучше делать на рабочем сервере.
А еще можно использовать что-то типо backbone или же вообще сметится в сторону от jquery если у вас серьезный ui интерфейс, есть же библиотеки которые лучше заточне под ui.

А вот это:
//вызов так
$('#div').child({ name: 'hello world' });
var chld = $('#div').data('child');
chld.func1('');
chld.func3();

//либо
$('#div').child({name:'hell'});
$('#div').child('func1', '');

опять же ведет к путанице и ничем осбо не помогает, я вот не понимаю чем это лучше стндартного механизма jquery
Приведенный пример переписанный с использованием jquery-ui будет выглядеть примерно так:

  $.widget('custom.base', {
    options: {
      name: ''
    },

    _create: function() {
      //some staff
    },

    func1: function(val) {
      //some staff
    },
    func2: function(val) {
      //some staff
    }
  });

  $.widget('custom.child', $.custom.base, {
    options: {
      name: 'some default value'
    },

    _create: function() {
      //some staff
    },

    func3: function() {
      //some staff
    },
    func4: function() {
      //some staff
    }
  });

  $('#div').child({ name: 'hello world' });
Sign up to leave a comment.

Articles