Эта команда добавит их в предыдущий коммит просто

Я поэтому стараюсь все изменения сохранять при помощи git commit --amend

а просто git commit?

ну или git rebase -i, если ты такой любитель крупных коммитов?

Ребят, смотрю тут курс Романа, остановился на 21 уроке - там скачали бандл синатры+бутстрапа (он чет безбожно ругался на jquery, - я обновил и бутстрап, и джквери - все заработало)

Типа - захотел сделать новую фичу, создал новую ветку, в этой ветке делаю первый коммит, а потом в него добавляю изменения при помощи git commit -- amend

Но чего-то Роман не объяснил, как работают вью

юзай rebase -i, ну

ну или git rebase -i, если ты такой любитель крупных коммитов?

Не люблю git rebase. Да и к тому же, коммиты у меня не крупные

так и я очем

просто у тебя практика очень самобытная

Konstantin, посмотри следующий урок и все будет яснее

Одна фича = одна ветка, в которой один коммит с реализацией фичи

обычно подобную технику используют с rebase -i

Если фичу поправить надо, то это делается вторым коммитом

обычно подобную технику используют с rebase -i

Я пробовал, мне не понравилось

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

но вижу при этом еще и верхний бар, хотя в login_attempt.erb только одна форма....

Константин, в синатре где-то запрятан общий макет сайта

В рельсах он лежит в app/views/layouts/application.rb

просто в предыдущих уроках при загрузке нового "вида" - он загружался полностью, а старый удалялся

А где в синатре, я уже не помню

Не, это нормально, то что ты сейчас видишь

я понимаю, но как это работает? почему эта форма подгружается в главный лэйяут?

Чтобы менюшка эта не появлялась, её надо вычистить, уже не помню где

Вложенные лэйауты

Да

54 строка

В неё вместо yield попадает всё, что в app.rb

И дальше в зависимости от маршрута

Черная дыра какая-то.

Layout.erb это как бы макет сайта

То представление, которое отображается всегда

А то, что в app.rb - непосредственно страницы сайта

Сделано это ради удобства и ради соблюдения принципа DRY

Потому как один и тот же код копипастить во все разделы app.rb это не круто

позвал разраба соседа

он рассказал про yield

спасибо и вам :)

позвал разраба соседа

если хочешь, то можешь создать пустой layout и вызывать его при вызове вьюхи

def admin_layout {:layout, ‘empty’} end

не надо никакой вьюхи

достаточно в контролере прописать layout :false

f^ ye lf^ njxyj

а, точно!

чет я не понял... а где в app.rb вообще строчка про загрузку layout.erb

или синатра по дефолту грузит этот файл?

или синатра по дефолту грузит этот файл?

по дефолту

Может, кто подсказать как лучше сделать: Есть STI. Допустим вагон, с дочерними классами купе и плацкарт. Есть один на всех контроллер с экшн create через базовый класс: def create @carriage = Carriage.new(carriage_params) end Есть params def carriage_params params.require(:carriage).permit(:train_id, :top_seats, :bottom_seats, :side_top_seats, :side_bottom_seats, :seats, :type) end Добавление вагона осуществляется через одну форму (form_for(carriage.becomes(Carriage)) do |f| ) в которой поля соответственно под все типы мест. Собственно вопрос в чем - как по правильному запретить добавление мест не соответствующих типу вагона, валидацией на absence в каждом дочернем классе? Или есть вариант поизящнее.

Ну, финкнетаны, кто как делал?

примерно вот такие воспоминания у меня от этого

Вспоминай как делал!

надо смареть, а я уже не могу

Давай я посмотрю.

водноимённом гитхабе должно быть

pchellovod там и всё такое

ну вот у тебя никак не валидируется

посмотрел

ну и отправляй как есть, параллельно задавая вопрос

так я и задал, молчит пока. До этогоу меня вариант был через permitted_params для каждого дочеренго класса, принято, но мол можно сделать изящнее - изящнее то можно, гляжу так и делают, не обратив внимания, что в итоге может придти нечто большее, чем ждали.

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

джиэкс пока не проходили! : )

понятно, что потом поля формы будут скрываться в зависимости от выбранного типа

ERROR: S client not available

вариант проверять тип вагона в шоу и рендерить соответствующий паршиал.

речь о создании

До этого у меня было так: def create @carriage = carriage_class.new(carriage_params(carriage_class)) end def carriage_class @carriage_class ||= params[:carriage][:type].constantize end def carriage_params(carriage_class) params.require(:carriage).permit(carriage_class.permitted_params) end В базовом классе: def self.permitted_params [:type, :train_id, :number] end B дочерних свои permitted_params Ментор говорит, что не место permitted_params в моделях.

В общем сказали не выпендриваться и делать как все:(

А в контроллер засунуть что не позволяет

Контроллер один для всех и базовго и дочерних классов.

На слух сложно..но парамсы в модели точно не должны быть

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

Я хз Чо там у тебя..ну сделай ввлидатор ещё

что у меня там я выше написал

Мало написал..либо несколько парамсов для всех классов

В конце концов добавляешь проверку что в парамсах и все..один if

Если 2 вагона конечно

Есть класс вагон и 4 подкласса со своими аттрибутами, это уже не один if

Есть ещё case

завтра дочерних классов станет 8

Сложно так гадать то

Разбивай create тогда..нафига в одном контроллере

Задача такая.

Именно 1 контроллером?

Ага и созданием инстансов через базовый класс.

И в вагоне больше 4 классов быть не может кстати

Почему же

Может.

Если больше это уже не вагон

Общий Плацкарт купе св

Пздц

Купе, сидячий, плацкарт, св, а еще какие-нибудь люкс с одной кроватью, люкс с душем - уже 6 классов

Ты когда на поезде ездил

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

при том при всем, что это был такой же вагон как и остальные

Ща найду Линк ..может поможет