Вход • Регистрация

Программирование в DIAFAN.CMS

  •
  • 25 января 2011 г.
  • Я тут обнаружил, что на некоторых форумах говорят, что главный минус diafan.CMS - это то, что она закостенелая и её практически невозможно править. Т.е. например, если надо добавить какое-нибудь поле в базу, например, к товару, и управлять им из админки, то это хана - никак!
    Типа, установили "как есть" и больше ничего в diafan.CMS не изменишь... Неужто?

    Есть у кого-то проблемы с изменением diafan.CMS? С программированием новых модулей или правкой старых? К чему нам присмотреться? Что доработать в документации?
    •
    • 25 января 2011 г.
    • Код
      Т.е. например, если надо добавить какое-нибудь поле в базу, например, к товару, и управлять им из админки, то это хана - никак!


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

      так и напишите этим специалистам.
      •
      • 25 января 2011 г.
      • извиняюсь. только сейчас заметил что рассказываю это разработчику системы)))
        ну в общем вы меня поняли. я считаю для доработки система супер
    •
    • 25 января 2011 г.
    • а есть где почитать эти форумы? интересно
      •
      • 25 января 2011 г.
      • Ну например, вот
        • 25 января 2011 г.
        • там 3 сообщения. второй явно не разобрался с системой и сделал поспешные выводы по поводу расширяемости.
          Почти всегда разрабатывая сайт, приходится добавлять что-то свое в код...те же поля доплнительные например. Имхо, в диафан все просто. Хотя может я не сталкивался с реально сложными задачами.
    •
    • 26 января 2011 г.
    • Тоже не вижу проблем. Если надо добавит что-то в базу, то просто добавляешь и всё потом где надо дописываешь имя поля и всё работает. Некоторые случаи совсем тривиальные и не требуют такого вмешательства, можно просто мышью натыкать.
      Можно конечно ещё видео урок сделать и по подробнее описать как правильно делать модуль. Как он должен быть укомплектован самый минимум и на что нужно обратить внимание при его проектировании чтобы обеспечить его лёгкую расширяемость.
      Что касается админки, я тоже ещё не во всём толком разобрался - потому что такой задачи не стояло но что было нужно сделать, удалось, не сразу, но и без особых напрягов.
      •
      • 26 января 2011 г.
      • Ага, т.е. урок "Как создать свой модуль" не помешает?
        •
        • 26 января 2011 г.
        • точно не помешает. только может не надо его видеоуроком?
          •
          • 27 января 2011 г.
          • Ну можно и тьютером. С картинками или прикреплять странички с кодом, подсвеченным цветом для наглядность. Ну в общем как-то так.
        •
        • 27 января 2011 г.
        • Не помешает. По крайней мере развитию ЦМС и появлению новых партнёров точно не повредит. Но стопудово не первостепенная важность. На первых порах и документации подробной с примерами хватило бы.
  •
  • 16 ноября 2011 г.
  • Над документацией сейчас плотно работаем, переделываем принцип. Будет все прозрачно и понятно! Зашел, прочитал - "ух ты как все просто"
    • 17 ноября 2011 г.
    • Было бы отлично. Мне например очень имонирует как это сделано у СodeIgnitor. Если чтото похожее будет то было бы куда проще для разработчиков. Разобраться как и что всё устроено. Хотя понятно дело что Маришки нет - этими делами некому заниматься.
      •
      • 17 ноября 2011 г.
      • Маришка скоро вернется
        А что Маришка? Она как Эйнштейн, только высокой наукой занимается, а тут нужно руководство для чайников с основами
        • 18 ноября 2011 г.
        • Ууу - значит я ошибался. Просто в основном она решала незначительные вопросы - в том числе и по руководству подсказывала, что и как, а её не стало и как-то всё тяжелее стало. Вон Гарик немного помогает, но в основном самому приходится теперь додумывать и бороться с проблемами :)
          Да Ждём ещё Маришку пол годика - побыстрее бы пролетело это время :)
          •
          • 18 ноября 2011 г.
          • Все верно, Гарик уполномочен решать все вопросы на время Марининого отсутствия, и мелкие и покрупнее
            P.S. Марина должна вернуться пораньше
  • 18 декабря 2015 г.
  • Лично у меня есть пара пожеланий.
    1.Слишком много условий при выводе в шаблонах,особенно в админке.Отслеживать поток крайне не удобно.Отступление от MVC ,к которой уже все привыкли.
    2.Во многих местах данные в шаблон передаются массивами а не объектами.Удобнее когда определенная часть объекта несет свою функцию и данные.
    3. <html><?php echo $var?></html> Смотрится на много эстетичней чем <?php echo "<html>"?>
    4. Документации для разработки маловато.
    •
    • 18 декабря 2015 г.
    • Может они (пожелания), и конструктивные, но как можно делать выводы о cms не ознакомившись с ней основательно?
      Цитата
      По роду своей деятельности работаю с разными системами.

      Сколько времени? Откуда вывод:
      Цитата
      4. Документации для разработки маловато.

      Делать выводы можно только после тщательного изучения.
      •
      • 18 декабря 2015 г.
      • Я думаю после тщательного изучения их было бы больше.Это поверхностные.Но не волнуйтесь их больше не будет.Потому что цели вступать в перепалку нет.-Нет потребности в понимании недостатков-нет пожеланий.К сей не конструктивной демагогии нет интереса.
        •
        • 18 декабря 2015 г.
        • Цитата
          <html><?php echo $var?></html> Смотрится на много эстетичней чем <?php echo "<html>"?>

          Подскажите, в чём эстетика? Это нулевой класс первая четверть.
          •
          • 21 декабря 2015 г.
          • Ага тоже терпеть не могу когда кругом
            Код
            <?php ... ?><p>бла бла</р><?php ... ?><p>бла<?php ... ?>бла</р><?php ... ?>
            Что это?
            •
            • 22 декабря 2015 г.
            • Такой способ, например, позволяет нормально работать мультиподсветке в редакторах и код воспринимать гораздо проще визуально. Другой вопрос, что делать так ради того, чтобы не писать echo для вывода пары тегов, то да - глупо. Но есть вполне себе обоснованные ситуации.

              В ряде случаев также пользуюсь операторами
              Код
              $x .= 'string';
              и вывожу переменную только после перечисления всех условий. Всему своё место.
  • 18 декабря 2015 г.
  • На мой взгляд приоритетной задачей должно быть удобство для разработчика,ведь основной распространитель вашей системы разработчик.И лишь потом пользователь.
    •
    • 18 декабря 2015 г.
    • Нет. Это мусолилось тыщу раз. Разработчик говорит клиенту "я вам поставлю бубубу.цмс", а клиент говорит "я хочу бибибитри, я слышал он понтовый". Разработчик говорит "но в бибибитри говняный код и неудобная разработка!", клиент отвечает "ничего не хочу слышать, надо только бибибитри, плачу любые деньги". И всё. И разработчик уныло идет ставить пользователю бибибитри. А может и радостно, бабки-то платят.
      А уже те из пользователей, кому пофиг, джумла или куку.цмс, им да, им можно поставить что пожелает разработчик. Но если для клиента нет разницы, разработчику зачем платить за лицуху? Он и воткнет вордпресс...
      Так что надо со стороны клиентов заходить, им лизать попу интерфейсом и функционалом. И когда клиент готов платить, и машет пачкой денег перед носом разработчика, то разработчик из кожи вылезет, но будет и кривой поток отслеживать, и с эстетичностью мириться.
      •
      • 18 декабря 2015 г. , редакция: 18 декабря 2015 г.
      • Это так.Тогда зачем этот форум?Не является ли его целью улучшение кмс?Разве постараться учесть потребности всех сторон-это не развитие системы? Разработчик может лицуху и не возьмет.Зато будет советовать.Самая эффективная реклама во все времена была и будет -это сарафанное радио.
        •
        • 18 декабря 2015 г.
        • Форум зачем? Поговорить. Чем мы и занимаемся
          • 18 декабря 2015 г. , редакция: 18 декабря 2015 г.
          • Цитата
            Есть у кого-то проблемы с изменением diafan.CMS? С программированием новых модулей или правкой старых? К чему нам присмотреться? Что доработать в документации?
            •
            • 18 декабря 2015 г.
            • Ладно бы только пожелания и замечания.
              Но когда начинают учить жизни и как работать в формате
              Цитата
              приоритетной задачей должно быть удобство для разработчика,ведь основной распространитель вашей системы разработчик.И лишь потом пользователь.
              можно только головой покачать. А вот ты что! (и сам себя по лбу ладошкой) А мы ты-то, дурачки глупенькие, сидим десять лет дурака валяем.. А оказывается вон как надо!
    • 18 декабря 2015 г.
    • Глеб Зверев, стаж 1 месяц, нет лицензий.
      Если бы текст выше написал наш годовалый партнер хотя бы, разработавший несколько сайтов, был бы другой разговор. А когда приходит человек, и с порога говорит "мне у вас неудобно, переделывайте", это странно выглядит. Может просто Вам одному пока просто непривычно?
      • 18 декабря 2015 г.
      • А-а, какой там месяц стажу?"Регистрация: сегодня, 13:41", час назад! Вы для этого зарегистрировались, чтобы написать пожелание по переделке системы?
        • 18 декабря 2015 г. , редакция: 18 декабря 2015 г.
        • Нет .Не для этого.Искал решение возникшей проблемы.Сами подумайте -как у меня возникли пожелания при отсутствии лицензии.С чего вдруг?Потому что я злодей?
  •
  • 18 декабря 2015 г. , редакция: 18 декабря 2015 г.
  • Я не покупаю лицензии ,Я работаю с системами которые уже купили,Я это делаю не для себя.Вашу систему приобрели у меня не спросили.По роду своей деятельности работаю с разными системами.Пришлось по работать и с вашей.
  •
  • 18 декабря 2015 г.
  • Я написал не для того чтоб спорить,на мой взгляд я описал вполне конструктивные пожелания,И не было цели как то скомпрометировать вашу работу
  •
  • 18 декабря 2015 г.
  • Вообще непонятно, о чем разговор.
    Лично мне тоже поначалу казалось многое неудобным, просто потому, что для меня это непривычно. Привыкла работать с другими цмсками.
    Выбрала диафан по двум критериям: взломоустойчивости и удобству переезда с другого движка. Оба эти параметра меня удовлетворили.
    Да, некоторые доработки до сих пор не сделаны, но тут виновата моя занятость/лень или другое (нужное подчеркнуть).

    Не совсем нравится, что на форуме мало готовых решений, из-за чего приходится доставать ТП, а я не люблю этого делать. Но это уже моя личная любовь/не любовь, создающая неудобства только мне.
    •
    • 21 декабря 2015 г.
    • Зато сколько опыта в области разработки появляется А? Согласитесь! :)
  •
  • 22 декабря 2015 г. , редакция: 19 ноября 2016 г.
  • Цитата
    К чему нам присмотреться? Что доработать в документации?

    Хорошо бы разжевать некоторые вроде бы элементарные моменты, но новичку совершенно не очевидные.

    1. Например, в доках указывается, что такой-то шаблон отвечает за внешний вид такого-то блока. Например, cart.view.show_block.php. Там кода немного и разобраться просто, что туда по ходу пьесы включается другой шаблон
      2. Код
      echo '<span id="show_cart" class="js_show_cart">'.$this->get('info', 'cart', $result).'</span>';

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

      Я себе даже функцию отдельную написал, которая мне через __FILE__ выводит название путей/имён шаблонов, отвечающих за тот или иной блок/участок страницы.

    2. Другой момент: есть совершенно понятный раздел документации про вывод характеристик в любом месте. Только не совсем в любом. Надо мне вывести доп.характеристику, не влияющую на цену, в блоке корзины, а нельзя, поскольку она не попадает в $result.

      3. Решил получить через магазин (тем более я так уже получил данные по ценам)
      Код
      $prices = $this->diafan->_shop->price_get_base($row['id']);

      Оказалось, что объект числится как private и получить какие-либо данные я могу только через существующие методы. Поскольку явно в документации доступные методы не перечисляются, я решил прибегнуть к помощи функций get_class_methods().

      Решил разбираться на уже опробованной конструкции и вообще не нашёл метод price_get_base() из примера выше. Подумал: "Мало ли я чего не понял?", - и прошёлся по всему дистрибутиву текстовым поиском. И опять ничего. Т.е. явного описания метода price_get_base() в файлах дистрибутива нет. А нет потому, что price_ добавляется как префикс в одном из файлов модуля магазина. И это также не очевидно, как и в предыдущем случае с подключением шаблонов. Я не прочёл документацию от корки до корки. возможно, что перечисление методов в одном месте где-то есть (ткните носом, если есть).

    3. Обратите внимание на то, как сделано в MDN. Описывается, допустим, функция. После описания принципа идёт пример синтаксиса, в котором полностью указаны все параметры. В документации диафана с этим в некотором смысле беда. Описан шаблонный тег, в описании в виде текста даны его параметры. А пример с синтаксисом - короткий с 1-2 параметрами, хотя их у тега может быть 8.

      4. Некоторые вещи тут опять-таки не всегда и не всем очевидны. Указываете синтаксис шаблонного тега - укажите полностью все параметры, как они должны быть. А уже потом указывайте какой хотите частный случай хоть с одним параметром, хоть вовсе без него.

    4. Ну и последний момент - было бы здорово в графическом или псевдо-графическом варианте видеть дерево подключения файлов при формировании страницы. Так структура будет абсолютно прозрачной. Начинается всё с index.php и далее по списку. Как-то так:
      5. Код

      index.php
      |
      |__file_1.php
      |
      |__fil_2.php...

      Из этой же серии поднятые выше вопросы по подключению шаблонов, пречислению методов и синтаксису шаблонных тегов.

      Сделать эти вещи не сложно и дёшево с точки зрения трудозатрат. А вот польза в понимании структуры построения и взаимодействия всего и вся, как мне кажется, огромна. Поскольку намного проще дать человеку карту, чем объяснять: "Отсюда 300 шагов на север, там речка, потом холм, как с него спустишься, увидишь пенёк и т.д. и т.п..". Надо полноценно визуализировать структуру.



    • 22 декабря 2015 г.
    • Павел, Глеб Зверев поднял очень старую тему.
      Цитата
      К чему нам присмотреться? Что доработать в документации?
      - это цитата собщения 2011 года, пятилетней давности. Тогда у нас была совсем простая и короткая документация без возможности комментирования.
      Это я к тому, что Вы говорите очень правильные вещи, но, к сожалению, эта тема уедет и всё забудется. Мы сейчас поглощены 6.0 и не можем кинуться вносить исправления в доки.
      Цитата
      Хорошо бы разжевать некоторые вроде бы элементарные моменты, но новичку совершенно не очевидные.
      Это да. Но эти дельные замечания лучше оставлять ровно в том разделе документации, где они ожидаются. Главная проблема в чем? В том, что у нас глаз замылен по документации. Нам кажется, что вроде все очевидно. Поэтому читаете - непонятно - хоп коммент "Это-то и это-то не понятно, прошу разъяснить". Мы и разъяснять стараемся и доки редактируем с учетом этого замечания.
      Цитата
      Ну и последний момент - было бы здорово в графическом или псевдо-графическом варианте видеть дерево подключения файлов при формировании страницы. Так структура будет абсолютно прозрачной.
      Да, но где? В каком именно разделе такое дерево ожидается увидеть? Например, мы забубенили вот такую подобную схему http://www.diafan.ru/docs/dokument/full-manual/templates/design/inside_design.png видели Вы её?
      •
      • 23 декабря 2015 г. , редакция: 23 декабря 2015 г.
      • Тема может и старая, но идеи, которые я высказал (лично для меня) актуальные и в некотором смысле злободневные.
        Цитата
        Мы сейчас поглощены 6.0 и не можем кинуться вносить исправления в доки.
        Я, собственно, этого и не требую. Это просто нюанс, который будучи реализованным, сильно повысит (имхо) DiafanCMS в плане лёгкости освоения.
        Цитата
        Да, но где? В каком именно разделе такое дерево ожидается увидеть? Например, мы забубенили вот такую подобную схему http://www.diafan.ru/docs/dokument/full-manual/templates/design/inside_design.png видели Вы её?
        Схему эту видел, она хорошая и наглядная. Но это всё же частный случай во всех отношениях и к тому же картинка (по ней поиском не "пробежишься"), причём там очень много всего и сразу.

        Схему (если она появится) лично мне хотелось бы видеть в разделе с говорящим названием "Архитектура DiafanCMS". Оставлю комментарий там, если так эффективнее.

Новости

  • Не пропустите сборку DIAFAN.CMS 7.1.4
  • 24 апреля, среда
  • В новой сборке совершили революцию в структурировании кастомизированной информации в шаблонах, добавили авторегистрацию пользователей, усовершенствовали защиту от спама, актуализировали накопительную скидку, а также улучшили производительность и стабильность работы системы.
  • Сборка DIAFAN.CMS 7.1.3
  • 12 января
  • После выхода сборки 7.1 мы выпустили уже три патча, в каждом из которых улучшаем административную часть сайта. Сборка DIAFAN.CMS 7.1.3 уже доступна к установке. 
  • Новость. Сборка. Тарифы
  • 15 декабря 2023 г.
  • Подводим итоги 2023 года. Выпустили новую сборку DIAFAN.CMS 7.1.1, вводим новые тарифы на аренду сайта и коммерческую поддержку и автообновления с января 2024 г., строим планы на будущий год.
Все новости