Зависит от специфики магазина. При необходимости для конкретного магазина всегда можно добавить ссылку «Продолжить покупки» или сделать добавление товаров в корзину при помощи AJAX. Я не считаю, что этот аспект принципиален для демо-магазина.
Причём тут Integer#to_i? Ваш вариант эквивалентен вызову:
puts gets.split.inject("") { |memo, num| num.to_i + memo.to_i }
Это в принципе работает, но складывать числа, помещая промежуточные результаты в строку, — это явно плохой пример новичкам. Да и вообще абсурдно как-то, не?
Если сомневаетесь, что аккумулятор в вашем примере строка, можете попробовать:
puts gets.split.inject { |memo, num| num.to_i + memo }
Проблема в том, что в этих csv/xml-файлах хранятся совершенно разные данные, общее для всех только название товара и цена, все остальные поля зависят от конкретного прайса.
Под конкретного заказчика — нет проблем, а что-то универсальное делать — времени нет. Если у Вас есть достаточно свободного времени для создания универсального решения для импорта произвольного набора данных и желание его реализовать, то я только за. Можно обсудить в личке.
Спасибо за замечания. По первым трём пунктам всё понятно, исправлю к следующей минорной версии.
По п.4., насколько я понял, меняется размер вложенного textarea, а не YUIRichEditor.
По п.5. действительно странное поведение под Chrome, выпадающие меню визуального редактора в принципе видны, но они как раз и дают вертикальный скролл.
П.6. похоже тоже имеет смысл, надо подумать…
Из условия задачи: «Количество чисел меньше 10000». Я конечно понимаю, что на современных мощностях преобразовать строку, размером порядка 25 кб, в массив — это фигня. Но в рамках спортивного программирования так не делается. Уж слишком бросается в глаза неоптимальность использования массива для решения данной задачи.
А если уж гнаться за минимальностью кода, то можно ж ещё на 7 символов сократить:
p gets.split.map(&:to_i).max
Ну это в рамках исправления неправильного использования inject…
А вообще все подобные решения неправильны, где запросы типа «Введите первое число: », «Введите второе число: »? Валидация входных данных напрочь отсутствует. А решения с inject вообще решают какую-то другую задачу, ведь они легко могут просуммировать и больше, чем 2 числа.
Я, наверно, вас сильно удивлю, но бывают случаи когда от хранимых процедур никуда не денешься и это реальная необходимость для Rails-проекта.
Что касается, обеспечения ссылочной целостности, то это задача СУБД и лучше уж реализовать её и в ключах и в моделях, чем только в моделях и потом получать пачками «NoMethodError: undefined method `xxx' for nil:NilClass».
Меня попросили показать, как и что умеет ActiveRecord в рельсах, я показал.
Мне показалось, что там было всего пару слов про ActiveRecord, всё остальное — про генераторы кода, миграции и прочие приятности, не имеющие ни малейшего отношения к ORM.
Про 20 лет — просто наблюдение человека, смотрящего со стороны. Такое все жалкое, недоделанное (Entity Framework, Fluent) и тд.
Почитайте Фаулера «Patterns of Enterprise Application Architecture», Active Record ничуть не современнее, чем Data Mapper. Если вы не понимаете смысла незнакомого паттерна, это ещё не значит, что его реализация «жалкая и недоделанная», просто паттерн призван решать задачу по другому и ожидать что NHibernate, реализующий Data Mapper, когда-либо станет похож на Active Record из Rails (а видимо именно по мере похожести определяется доделанность в вашем случае) по меньшей мере очень странно.
Руби озадачивает скоростью, этого достаточно, чтобы во многих нишах о нем даже не вспоминать.
Ну причём тут скорость, мы тут что вообще обсуждаем архитектурные решения или синтетические тесты, результаты которых ничего не значат в реальном мире.
И да, я не видел ни одного крупного проекта, написанного на руби/рельсах с помощью DataMapper'a вместо AR.
А уверен, что видел код всех крупных проектов на руби?
А если серьёзно, существующая для Ruby реализация паттерна Data Mapper, с одноимённым названием, сильно упрощённая и по сути похожа на ActiveRecord под другим углом. О существовании готовых решений уровня Hibernate под Ruby мне не известно.
Спасибо, я знаю про плагин, поэтому и написал «из коробки», вообще логично было бы включить эту функциональность в Rails.
> Но вообще говоря, в рельсах есть штуки, на которые люди, умеющие готовить sql, смотрят с презрением.
Ну такие штуки есть в любом ORM, именно поэтому надо понимать как конкретный ORM работает и какие запросы он генерирует за кадром, иначе такой фигни можно понаписать…
А вообще Active Record в Rails очень прилично реализован, ему бы ещё поддержку DISTINCT получше сделать и вообще шикарно будет :-)
В файле модели user.rb нужно (между class и end) написать has_many :posts, :dependent => :destroy, а у поста — наоборот belongs_to :user.
Теперь если мы удалим юзера, удалятся все его посты (dependent можно не указывать, тогда не удалятся)
Управление ссылочной целостностью данных на уровне приложения — это не та вещь, которой стоит гордиться… А вот задать нормальные foreign keys на уровне БД в Rails, к сожалению, до сих пор довольно сложно, если не использовать raw SQL под конкретную СУБД, особенно «из коробки».
> NHibernate — это ActiveRecord из Rails, сделанный будто бы лет 20 назад.
Это фактическая ошибка. NHibernate реализует сложный набор паттернов: Data Mapper, Identity Map, Unit of Work.
ActiveRecord в свою очередь реализует паттерн Active Record, который является одним из самых простых вариантов реализации ORM, и даже нарушает SRP (принцип единственной ответственности) для сохранения максимальной простоты.
И хоть я сам сейчас программирую преимущественно на Ruby, мне кажется, не очень этично глумиться над людьми, которые в силу специфики своих проектов вынуждены использовать более сложное решение на основе Data Mapper, а не простенькое на основе Active Record.
P.S. На всякий случай упомяну, что паттерн Active Record реализован для всех популярных языков, а не только для Ruby.
Так что принципиальные отличия в паттернах «Data Mapper vs Active Record», а не в Rails. Одно из ключевых отличий состоит в том, что Data Mapper создаёт объекты на основе произвольного набора данных из базы данных, а Active Record на основе одной единственной таблицы в базе данных.
P.P.S. Миграции к ORM вообще никакого отношения не имеют, они относятся к вопросу создания и редактирования схемы базы данных, а не к вопросу преобразования отношений в объекты.
Согласен, inherited_resources — это вещь в стиле «как сделать простые вещи сложными». Если в проекте много однотипных простеньких контроллеров, то в разы лучше будет создать обычный базовый класс контроллера с минимумом магии и метапрограммирования, который идеально подойдёт под потребности конкретного проекта.
А использовать inherited_resources для нетривиальных контроллеров == снижать читабельность кода в разы.
Мануал: spreecommerce.com/documentation/customization.html
Идёт работа над дальнейшем упрощением внесения изменений в шаблоны. В 0.70 для этого будет задействован Deface
puts gets.split.inject("") { |memo, num| num.to_i + memo.to_i }
Это в принципе работает, но складывать числа, помещая промежуточные результаты в строку, — это явно плохой пример новичкам. Да и вообще абсурдно как-то, не?
Если сомневаетесь, что аккумулятор в вашем примере строка, можете попробовать:
puts gets.split.inject { |memo, num| num.to_i + memo }
Сильно востребованные возможности попадут в Roadmap на следующие релизы.
Под конкретного заказчика — нет проблем, а что-то универсальное делать — времени нет. Если у Вас есть достаточно свободного времени для создания универсального решения для импорта произвольного набора данных и желание его реализовать, то я только за. Можно обсудить в личке.
Мда, видимо Яндекс в очередной раз поменял формат выдачи… Чувствую придётся эту возможность выносить в отдельное расширение.
> «Поддержка юр.лиц» — можно поподробнее, какие у вас планы?
В первую очередь возможность выставления счёта для своей организации после оформления заказа.
> Планируется ли пакетная загрузка товаров, прайс-листов?
Пока она делается только под заказ, какой-то универсальный механизм под любой формат прайс-листов в ближайшее время не планируется.
По п.4., насколько я понял, меняется размер вложенного textarea, а не YUIRichEditor.
По п.5. действительно странное поведение под Chrome, выпадающие меню визуального редактора в принципе видны, но они как раз и дают вертикальный скролл.
П.6. похоже тоже имеет смысл, надо подумать…
А если уж гнаться за минимальностью кода, то можно ж ещё на 7 символов сократить:
p gets.split.map(&:to_i).max
puts gets.split.inject(0) { |memo, num| num.to_i + memo }
Ну это в рамках исправления неправильного использования inject…
А вообще все подобные решения неправильны, где запросы типа «Введите первое число: », «Введите второе число: »? Валидация входных данных напрочь отсутствует. А решения с inject вообще решают какую-то другую задачу, ведь они легко могут просуммировать и больше, чем 2 числа.
Что касается, обеспечения ссылочной целостности, то это задача СУБД и лучше уж реализовать её и в ключах и в моделях, чем только в моделях и потом получать пачками «NoMethodError: undefined method `xxx' for nil:NilClass».
Почитайте Фаулера «Patterns of Enterprise Application Architecture», Active Record ничуть не современнее, чем Data Mapper. Если вы не понимаете смысла незнакомого паттерна, это ещё не значит, что его реализация «жалкая и недоделанная», просто паттерн призван решать задачу по другому и ожидать что NHibernate, реализующий Data Mapper, когда-либо станет похож на Active Record из Rails (а видимо именно по мере похожести определяется доделанность в вашем случае) по меньшей мере очень странно.
Ну причём тут скорость, мы тут что вообще обсуждаем архитектурные решения или синтетические тесты, результаты которых ничего не значат в реальном мире.
А уверен, что видел код всех крупных проектов на руби?
А если серьёзно, существующая для Ruby реализация паттерна Data Mapper, с одноимённым названием, сильно упрощённая и по сути похожа на ActiveRecord под другим углом. О существовании готовых решений уровня Hibernate под Ruby мне не известно.
> Но вообще говоря, в рельсах есть штуки, на которые люди, умеющие готовить sql, смотрят с презрением.
Ну такие штуки есть в любом ORM, именно поэтому надо понимать как конкретный ORM работает и какие запросы он генерирует за кадром, иначе такой фигни можно понаписать…
А вообще Active Record в Rails очень прилично реализован, ему бы ещё поддержку DISTINCT получше сделать и вообще шикарно будет :-)
Управление ссылочной целостностью данных на уровне приложения — это не та вещь, которой стоит гордиться… А вот задать нормальные foreign keys на уровне БД в Rails, к сожалению, до сих пор довольно сложно, если не использовать raw SQL под конкретную СУБД, особенно «из коробки».
Это фактическая ошибка. NHibernate реализует сложный набор паттернов: Data Mapper, Identity Map, Unit of Work.
ActiveRecord в свою очередь реализует паттерн Active Record, который является одним из самых простых вариантов реализации ORM, и даже нарушает SRP (принцип единственной ответственности) для сохранения максимальной простоты.
И хоть я сам сейчас программирую преимущественно на Ruby, мне кажется, не очень этично глумиться над людьми, которые в силу специфики своих проектов вынуждены использовать более сложное решение на основе Data Mapper, а не простенькое на основе Active Record.
P.S. На всякий случай упомяну, что паттерн Active Record реализован для всех популярных языков, а не только для Ruby.
Так что принципиальные отличия в паттернах «Data Mapper vs Active Record», а не в Rails. Одно из ключевых отличий состоит в том, что Data Mapper создаёт объекты на основе произвольного набора данных из базы данных, а Active Record на основе одной единственной таблицы в базе данных.
P.P.S. Миграции к ORM вообще никакого отношения не имеют, они относятся к вопросу создания и редактирования схемы базы данных, а не к вопросу преобразования отношений в объекты.
А по поводу даблклика на вкладке, я тоже не понял в каких ситуациях это может быть удобно для обновления страницы…
А использовать inherited_resources для нетривиальных контроллеров == снижать читабельность кода в разы.