Сергей Протько: я наоборот боюсь, что это значение может быть расшарено. К сожалению, я уже сделал контроллер, который содержит некие параметры. Можно ли это оставить работать (пока что) или нужно срочно перекидывать всё в модель?
Мне кажется, что автор вопроса просит более опытных людей прокомментировать его верстку, указать на ошибки, т.к. ему показалось, что его верстка крива.
Mikhail Osher: SPA - что это? Простите, я вас не понял) Мне просто не нравится, что когда, например, я вызываю action без вызова render в конце (когда нужно что-то протестить и вывести информацию с echo), то попадаю на белый экран, откуда никуда потом не уйти. Поэтому я переопределил контроллер так, чтобы он рендерил пустую страницу, когда рендер "пользователем" не вызван. А после заметил, что это дало эффект в ajax - с нужной инфой грузится layout
Mikhail Osher: у меня переопределен render так, чтобы при экшене без рендера, layout все равно загружался (экран не оставался пустым), проблема в том, что при ajax подгрузке renderPartial, вместе с нужной инфой, подгружается внешний layout, вот хочу это изменить.
как-то так =) но на вопрос это никак не влияет)
Виталий Кузнецов: возможно, но думаю что serialize оставляет мусор, я бы просто оставил координаты через знаки разделители максимально компактно, может, если есть желание и возможность, еще заархивировать)
evgenybuckharev: для универсальности (модульности), чтобы ни одна таблица не зависела от другой. Для меня это достаточный аргумент, мне так проще) Тем более плохого влияния на работу приложения это не оказывает, а скорость запросов пока меня устраивает
evgenybuckharev: у меня сложилось ощущение, что вы вопрос не читали)
По идее хотел сделать связь many-many с обеих сторон для универсальности, но т.к. вывожу я все равно 1 категорию на страницу, решил что это лишнее, и сделал связь "одна категория - много страниц".
Следовательно - у page одна категория, точнее page BELONGS_TO category, category HAS_MANY page.
evgenybuckharev: документацию читал, повторюсь - хотел сделать связь many-many с обеих сторон для универсальности, следовательно и сделал эту структуру таблиц, не думаю, что на этот счет есть какие-то строгие правила. Если вдруг мне придется переделывать с belongs_to/has_many в many-many - не придется возиться с таблицами для этого.
Да, думаю что Байес это лишнее, из раздела вероятностей, думаю, лучше вообще ничего не трогать.
Мне кажется, что максимально упростить с таким количеством параметров не получится. Гугление может помочь. Вот например что мне попалось - Вычислительная гидродинамика
Я бы либо написал "грубый" физический движок, без частиц, чисто стандартные формулы из физики, +немного магии для парения самолетика, либо использовал готовый, но с частицами.