Solmyr: метод, который отвечает надо или нет добавлять элемент интерфейса, именно у самого объекта. Это логично.
Так "может"-то (редактировать/удалять) пользователь.. а не объект =) И да, пользователь один "на страничку" (отображаемую в браузере).. а объектов - много..
Если очень хоцца.. можно, конечно добавить для объекта некое isEditable (by)
if ($post->is('editable', $user))
При этом реализацию опять же убрать в
ivan-lev:
Gate::check($user, 'update-post', $post)
Solmyr: добавлять элемент интерфейса, именно у самого объекта
кхм.. если тут объект - это не экземпляр класса, а кусок HTML-кода, то в любом случае он выводится (на страничку) для текущего пользователя..
Sitealert: Список объектов - это и есть список ролей, фактически.
Думаю, речь о том, что на текущий момент ТС не видит смысла вводить дополнительный слой абстракции "лишнюю" сущность "роль". Т.к. в итоге всё завязано на user-а.. (по сути - у всех одна роль "авторизованный пользователь", а логика сводится к разрешению отдельных прав (на редактирование?) доступа к конкретным объектам)..
order-md-1
а вот смешения влево нету?
А смешение влево по умолчанию при использовании колонок стоит..
Задача-то какая?
Можно использовать
илиhttps://stackoverflow.com/questions/4008406/upload-a-whole-directory-through-an-html-form
http://sapphion.com/2012/06/12/keep-directory-structure-when-uploading/
PS - Не думал что jquery будет работать в апи 2гиса, поэтому даже не пробовал туда втыкать снятие класса.
У Вас первой строчкой в JS 😎
$(document).ready(function(){
Клиентам сайта не нужно настраивать подключение к сайту по HTTPS. Это лежит исключительно на вашей стороне.
А причём тут клиенты сайта? =)
Речь о клиентах, заказывающих сайт.. :)
метод, который отвечает надо или нет добавлять элемент интерфейса, именно у самого объекта. Это логично.
Так "может"-то (редактировать/удалять) пользователь.. а не объект =) И да, пользователь один "на страничку" (отображаемую в браузере).. а объектов - много..
Если очень хоцца.. можно, конечно добавить для объекта некое isEditable (by)
if ($post->is('editable', $user))При этом реализацию опять же убрать в
добавлять элемент интерфейса, именно у самого объекта
кхм.. если тут объект - это не экземпляр класса, а кусок HTML-кода, то в любом случае он выводится (на страничку) для текущего пользователя..
Список объектов - это и есть список ролей, фактически.
Думаю, речь о том, что на текущий момент ТС не видит смысла вводить дополнительный слой абстракции "лишнюю" сущность "роль". Т.к. в итоге всё завязано на user-а.. (по сути - у всех одна роль "авторизованный пользователь", а логика сводится к разрешению отдельных прав (на редактирование?) доступа к конкретным объектам)..
// Фильтрация и проверка данных PHP , первое что попалось
}
Код обработчика данных
Т.е. фильтрация и проверка - это не обработка? =)
А комбинации и зоопарки методов - это не хорошо. Потом баги стадами ходить будут.
Под комбинацией имел в виду, что логика
$user->can('update-post',$post)реализуется путём чего-то похожего на:
Первое более логично.. второе - суть.
Значит, надо сделать. И получится – в варианте 2 проверка варианта 1.
На самом деле, они есть.. Даже если явно не обозначены.. Как минимум...
- администратор
- авторизованный пользователь
- гость
Просто перейти от проверки вроде
к более абстрактному и расширяемому..
Solmyr, на самом деле, можно любым из вариантов (и их комбинацией) к чему-то интересному прийти.. Главное - начать.. ))