LiveStreet CMS

• benone
• 8 сентября 2009, 13:08
• 0

надо смотреть javascript-ошибки.

Блог им. Tozz → Не работают JS-библотеки 26

• benone
• 8 сентября 2009, 12:36
• 0

Значит, проблемы с чем-то еще. JS должен выполняться

Блог им. Tozz → Не работают JS-библотеки 26

• benone
• 8 сентября 2009, 12:04
• 0

Какой код? джаваскрипт вставляется в теги literal вот так:

{literal}
alert("1");
{/literal}

Блог им. Tozz → Не работают JS-библотеки 26

• benone
• 3 сентября 2009, 15:31
• 1

Копирайты поставить надо=)

Сайты на LiveStreet → Проект "для свободных и интересных людей" 9

• benone
• 21 августа 2009, 10:52
• 0

Макс, штук 5 скринкастов «как создать плагин под ЛС» и начальное освоение закончено=) Обещаю, написать один под новую версию:)

Другое дело, если твой движок используют потому что под него УДОБНО разрабатывать сайты.

Кстати, вот примеры скринкастов фич rails: railscasts.com)

Предложения и пожелания → Ruby On Rails - best practices 49

• benone
• 21 августа 2009, 10:37
• 0

Макс, думаешь $db->query() причина большой аудитории девелоперов?
Мне кажется всё-таки следствие, потому что ВП один из первых блоговых движков. Тем более с системой плагинов.

Предложения и пожелания → Ruby On Rails - best practices 49

• benone
• 21 августа 2009, 02:17
• 0

Вообще, конечно хорошо бы иметь возможность вернуть и то и другое…

Например, когда мы постим ajaxом топик, возвращается html главной (который подгружаем тем же шаблоном, что и обычно, только без хидера/футера) и json, который мы обрабатываем и задаем классы элементов, который на странице.

Блог разработки LiveStreet → Новая структура и новые конфиги 89

• benone
• 21 августа 2009, 01:06
• 0

Опять же хочу сказать что основная цель у меня не доказать что я прав и всё знаю, а просто показать что есть и как это работает… Чтобы можно было подумать.

Предложения и пожелания → Ruby On Rails - best practices 49

• benone
• 21 августа 2009, 01:05
• 0

Признаюсь, не имел дела с такого вида наследованием. Со стороны звучит страшновато, хотя если есть и пользуются, значит кому-то это нужно:)

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

Предложения и пожелания → Ruby On Rails - best practices 49

• benone
• 21 августа 2009, 01:02
• 0

Да решать даже не мне:)

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

Предложения и пожелания → Ruby On Rails - best practices 49

• benone
• 21 августа 2009, 00:59
• 0

от «вполне годен» до «удобен» и «оптимален» далекая дорога. Хотя второго крайне сложно достигнуть. Чем-то всегда приходится жертвовать…

Предложения и пожелания → Ruby On Rails - best practices 49

• benone
• 21 августа 2009, 00:55
• 0

а это уже немного другое:)

Я имел в виду генератор — скрипт, который генерит код. А откуда будет грузиться код это уже дело не генератора…

Предложения и пожелания → Ruby On Rails - best practices 49

• benone
• 21 августа 2009, 00:54
• 0

да зачем всё усложнять? mysql_query()

Предложения и пожелания → Ruby On Rails - best practices 49

• benone
• 21 августа 2009, 00:51
• 0

1. Вы можете наследовать sql и tpl?
При генерации может создаться много ненужного кода, который можно просто удалить.

Предложения и пожелания → Ruby On Rails - best practices 49

• benone
• 21 августа 2009, 00:41
• 0

Я думаю, речь идет об отдельном классе генератора (в рельсах это вот: api.rubyonrails.org/classes/Rails/Generator/Base.html) который позволяет писать скрипты генерации проще.

Предложения и пожелания → Ruby On Rails - best practices 49

• benone
• 21 августа 2009, 00:39
• 0

Ну вообще, то что я написал ничуть не противоречит. Получается, это одно из свойств паттерна.

Да и вообще, тема топика не в Data Mappere, а в том как сделать ЛС лучше)

Предложения и пожелания → Ruby On Rails - best practices 49

• benone
• 21 августа 2009, 00:29
• 0

Там всё достаточно гибко.

Например, есть метод find_by_sql («select * from users»)…

Так же можно написать так:
user.find_all (:select => «select users.*, count (blogs.*)», :joins => :blogs, :group => «user_id»}

На счет друзей тут уже сложнее вечером написать на «языке» rails.

В любом случае всегда доступен find_by_sql

Более того, необходимые счетчики одной строчкой добавляются к табличкам (напр. кол-во комментариев пользователей).

Предложения и пожелания → Ruby On Rails - best practices 49

• benone
• 20 августа 2009, 23:55
• 0

Спасибо, забыл)

Предложения и пожелания → Ruby On Rails - best practices 49

• benone
• 20 августа 2009, 23:54
• 0

А если наоборот и модель использует несколько табличек, то можно их логически отделить так же… для пользователя

  has_one :address # табличка users соединяется с табличкой addresses по user_id

И мы используем user.address

Предложения и пожелания → Ruby On Rails - best practices 49

• benone
• 20 августа 2009, 23:52
• 0

Модели достаточно гибко расширяются и разделяются. Например, если есть пользователь(user) и у него есть адрес(address)

Можно всё это хранить в одной бд, но модель address будет расширять модель user и будет:

  new_address = конструктор нового адреса
  user.address = new_address

Хотя хранится всё в табличке users.

А в каких случаях может быть по-другому?

Предложения и пожелания → Ruby On Rails - best practices 49