только не юзаем

Тебе что конкретно от туда надо?

фронт по идее

но ваще хотелось чтоб и фронт и бэкенд были, лень писать свое

Тебе для админки или для юзеров?

для юзеров

тогда не подскажу

а для админки что-то есть?

Для админки я ckeditor + https://github.com/barryvdh/laravel-elfinder использую

печаль, придется писать бэк для этого мастадонта походу https://github.com/blueimp/jQuery-File-Upload

печаль, придется писать бэк для этого мастадонта походу https://github.com/blueimp/jQuery-File-Upload

так есть же, форматни под себя

так есть же, форматни под себя

где?

так гугл

печаль, придется писать бэк для этого мастадонта походу https://github.com/blueimp/jQuery-File-Upload

аха я с телефона думал это ежик))

аха я с телефона думал это ежик))

ну, судя по спагетти коду в примерах, вполне возможно.. в тумане..

Вопрос: Есть юзеры, есть заведения. У заведения может быть 1 админ и несколько редакторов. У каждого заведения есть тарифы. Бесплатный и 2 разных платных. Например у юзера 2 заведения, в обоих он админ. Одно хочет оплатить платный у другого бесплатный. Тарифы снимают бабло каждый день в полночь (грубо говоря). 1) Как сделать хранение инфы о том какой тариф у заведения? 2) Как сделать снимание бабла в определённое время с проверкой что все прошло правильно (то есть вдруг сервак лежал ровно в полночь минуту и не прошло снятие или другие причины)

интересно что ты хочешь услышать в ответ

ответы

обычно вопросы именно для этого задают

нет

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

вот первый вопрос. Текущий тариф хранить прям в таблице заведений?

А если решу добавить еще тариф? Или делать отдельно таблицу

таблицу под тарифы заведи

и пусть заведения ссылаются на нее

>1) Как сделать хранение инфы о том какой тариф у заведения? Тут лучше сделать отдельную табличку tariffs куда прописывать тарифы.

То есть в эту же таблицу и данные о стоимости наверно удобно будет занести, да?

ну я хз что за тарифы

а вот еще. Например я решу поменять стоимость тарифа. А у юзеров уже оплачено. Снимается каждый день определенная сумма. То есть и у уже оплативших начнёт сниматься бОльшая сумма, как избежать?

ну тариф даёт право например менять сео теги у своего заведения, видеть статистику, загружать меню, акции и тд

и шаблоны разные

Смотри, я бы сделал так: tariffs - id, name, price company_tariffs - id, company_id, name, price При назначении тарифа компании, копировал бы данные тарифы в tariffs

я так понимаю это Политиками лучше делать разделение доступов?

то есть прайс и там и там

Я специально так сделал бы

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

Чтобы на случай если в изначальном тарифе изменится цена, то у компании осталась бы прежняя

ага

нормально вроде

Просто уже сталкивался не раз.. "Мы хотим вот так", а потом "Нам надо менять это независимо от того что уже сделано"

ну вот да, я поэтому заранее и рассматриваю, а то знаю что надо будет потом иметь возможность менять

В итоге сначала делал просто табилцу с тарифами (например), а потом все равно приходилось делать отдельную и туда копировать данные

В итоге сначала делал просто табилцу с тарифами (например), а потом все равно приходилось делать отдельную и туда копировать данные

Спасибо, сделаю так

Спасибо (+1) для @Denormalization принято! Текущая карма +4

а бабло снимать, просто по крону? А если недоступен сервак? Заносить отдельно каждую попытку снятия? И проводить дополнительную попытку ночью еще пару раз? То есть чтобы в час еще раз проверить, если не удалось в полночь снять, то снова пробуем

На счет "как снимать" не подскажу. Тут все индивидуально.

или надо такоу статус снятия для каждого заведения делать?

ок, понял, буду думать

В общем случае да, крон

Но там может быть куча подводных камней.

так то принцип очень понятен, но уверен что есть мелочи которые в дальнейшем могут подпортить всё

А если у юзера денег на балансе нету?

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

А если он захочет отменить? А может он тратить на что-то другое?

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

А если он сделает вывод денег?

атата

баланс уменьшается, количество дней сразу меняется в атрибуте

а блин, сам баланс то один фиг надо уменьшать каждый день)) чот я туплю

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

Т.е админ баланс меняет, а крон ночью его обратно возвращал )

))

Так как баланс строился из другой БД на основе других данных )

Поэтому я не люблю связываться со всем где есть слова "Баланс", "Валюта", "Чардж"

Там обычно столько подводных камней, что заебешься разгребать.

там обычно надо думать ДО того как начал писать -)

там обычно надо думать ДО того как начал писать -)

думать надо заказчику, а они не умеют

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

Я не могу предвидеть все подводные камни, так как зачастую не знаю специфику бизнеса.

а заказчик не может предвидеть потому что не знает специфики кодинга

угу

столкновение

Из-за этого случается много косяков.

то есть заказчик сам не знает чего хочет?

то есть заказчик сам не знает чего хочет?

а ты встречал других?

это краевой случай. когда заказчик - наркоман -)

иногда даже банально, у поста есть категория. А потом заказчик говорит, надо добавить две категории на пост. Хотя изначально обсуждалось что только 1 категория. Ну как бы для заказчика то тут вообще кажется что все просто)

а ты встречал других?

честно я лет 12 как не встречал наркоманов. как перестал работать в веб-студиях

честно я лет 12 как не встречал наркоманов. как перестал работать в веб-студиях

да причем тут наркоманы? Заказчик - обычный человек. Он не может знать что тебе нужно для работы. И твоя задача у него все узнать. Но в ряде случае ты тоже не знаешь всей специфики, от сюда и проблемы.

+