T110E5: придет время и fb marketplace просто вытеснит классические "доски" как таковые.
xdemy: Авито, Циан, Зун, Я.Объевления существуют и будут существовать еще долгое время.
Я об этом писал несколько страниц назад и напишу еще раз. Для доски объявления самое главное - это удобный поиск. Кто сумеет сделать удобный поиск, тот и вытеснит всех. Сделает фэйсбук - будет фэйсбук, сделает Avito - будет авито. Сделает Вася Пупкин удобный поиск маляра в Самаре, пусть даже и на своей странице в соцсети, - будет Вася Пупкин.
ivan-lev: Геокодирование от "сторонних сервисов" есть. Вполне справляется. Можно приводить адреса к "единому виду" и искать с учётом этого..
Не так все просто. Адрес "ул. Петрова 16" сторонний сервис превратит в "ул. Петрова 17", если у этого стороннего сервиса дома номер 16 в базе нет. И адрес "ул. Петрова 18" - тоже. А адрес "ул. Петрова 16, квартира 23" - сторонний сервис превратит в "ул. Петрова 23", при условии если у сервиса в базе дом 23 есть, а дома 16 нет.
Таким образом у вас в исходном состоянии у вас было два разных адреса, а после использования "стороннего сервиса" - одинаковый. Или наоборот было два одинаковых дома с разной квартирой, - а стало два разных дома.
А еще могу рассказать, как сторонние сервисы интерпретируют "ул. Петрова 16/2" и "ул. Петрова 16 корпус 2" и "ул. Петрова 16/2 корпус 3". Корпуса не во всех городах РФ широко распространены, но есть такие города где "корпус" встречается чуть ли не в половине всех адресов.
А еще вот есть в городе проспект Гагарина, улица Гагарина, и бульвар Гагарина. Допустим адрес "ул. Гагарина 17" существует, а "проспект Гагарина 17" не существует. Что сделает сторонний сервис, если вы ему загадаете "Гагарина 17" или "пр. Гагарина 17"? Я уже не помню ответа на эти вопросы если честно, разбирался давно, но что-то не очень умное.
Если у вас адреса из коммунальных квитанций, то процентной долей ошибок можно пренебречь. А вот если у вас:
- адреса офисов фирм.
- адреса торговых точек.
- адреса объектов недвижимости.
- любые адреса в которых могут быть преднамеренные ошибки.
То никакой сторонний сервис не решит проблему поиска по адресам.
А еще у некоторых сторонних сервисов есть жесткие лимиты на количество запросов к геокодеру и конский прайс при превышении лимитов. Не будем называть имен, хотя речь про гугл. Поэтому их данные не всегда возможно использовать даже не для дела, а чисто в справочных целях.
Вот как раз с продвижением собственных сервисов в результаты поиска яндекс перебарщивает. В ЕС и США против этого есть антимонопольное законодательство. Но в России оно не работает. Потому никто не будет особо жалеть, если яндекс сосредоточится на поиске и откажется от сервисов.
Sirocco: Домен madonna*com забрали у бомжа за "недобросовестную конкуренцию" ?
В UDRP там иначе сформулировано. Там не "недобросовестная конкуренция" а "недобросовестные цели". Если еще точнее "bad faith". Это не имеет прямо вот дословного перевода на беларусский язык.
Как организовать с точки зрения структуры данных вопросов нет. Вопрос как с точки зрения программного кода.
---------- Добавлено 14.10.2019 в 08:13 ----------
Gerga: Что именно?
На самом деле, когда проверка прав происходит только при попытке выполнить действие над объектом, все просто. Любой из трех методов сгодится. Третий мне понравился с той точки зрения, что не инициализируем лишний код когда не надо.
Но вот есть ситуация: рисуем страничку приложения с объектами, объектов несколько или много. В том случае если у пользователя которому показываем страничку есть право сделать что-то с объектом (редактировать, комментировать, удалить, голосовать, скрыть) к объекту добавляется элемент интерфейса соответствующий. В такой ситуации хочется иметь метод, который отвечает надо или нет добавлять элемент интерфейса, именно у самого объекта. Это логично. Сейчас вот думаю тоже как его реализовать чтобы тоже лишний код не инициализировать когда не надо.
ivan-lev: Solmyr, на самом деле, можно любым из вариантов (и их комбинацией) к чему-то интересному прийти.. Главное - начать.. ))
Начато уже давно и давно работает. По третьему методу. Вот именно так как Gerga, говорит, с вспомогательными классами. Но вот при очередных расширениях функционала, стали меня терзать сомнения что это не совсем верно. Сейчас склоняюсь в пользу второго варианта, но пока еще не склонился окончательно. Продумываю разные сценарии. А комбинации и зоопарки методов - это не хорошо. Потом баги стадами ходить будут.
---------- Добавлено 13.10.2019 в 22:53 ----------
SeVlad: Почему нет если:
Потому что фактически один юзер - одна роль. Для каждого юзверя список объектов к которым есть доступ - разный. Причем даже не только просто юзер имеет доступ к своим объектам, а к своим "плюс" - где плюс просто разный список для разных юзеров.
Sirocco, По UDRP такой домен у сквоттера отобрали бы. Так что может быть и по другим мотивам, но беларусское правосудие пришло к тем же выводам что и цивилизованное.
придет время и fb marketplace просто вытеснит классические "доски" как таковые.
Авито, Циан, Зун, Я.Объевления существуют и будут существовать еще долгое время.
Я об этом писал несколько страниц назад и напишу еще раз. Для доски объявления самое главное - это удобный поиск. Кто сумеет сделать удобный поиск, тот и вытеснит всех. Сделает фэйсбук - будет фэйсбук, сделает Avito - будет авито. Сделает Вася Пупкин удобный поиск маляра в Самаре, пусть даже и на своей странице в соцсети, - будет Вася Пупкин.
Геокодирование от "сторонних сервисов" есть. Вполне справляется. Можно приводить адреса к "единому виду" и искать с учётом этого..
Не так все просто. Адрес "ул. Петрова 16" сторонний сервис превратит в "ул. Петрова 17", если у этого стороннего сервиса дома номер 16 в базе нет. И адрес "ул. Петрова 18" - тоже. А адрес "ул. Петрова 16, квартира 23" - сторонний сервис превратит в "ул. Петрова 23", при условии если у сервиса в базе дом 23 есть, а дома 16 нет.
Таким образом у вас в исходном состоянии у вас было два разных адреса, а после использования "стороннего сервиса" - одинаковый. Или наоборот было два одинаковых дома с разной квартирой, - а стало два разных дома.
А еще могу рассказать, как сторонние сервисы интерпретируют "ул. Петрова 16/2" и "ул. Петрова 16 корпус 2" и "ул. Петрова 16/2 корпус 3". Корпуса не во всех городах РФ широко распространены, но есть такие города где "корпус" встречается чуть ли не в половине всех адресов.
А еще вот есть в городе проспект Гагарина, улица Гагарина, и бульвар Гагарина. Допустим адрес "ул. Гагарина 17" существует, а "проспект Гагарина 17" не существует. Что сделает сторонний сервис, если вы ему загадаете "Гагарина 17" или "пр. Гагарина 17"? Я уже не помню ответа на эти вопросы если честно, разбирался давно, но что-то не очень умное.
Если у вас адреса из коммунальных квитанций, то процентной долей ошибок можно пренебречь. А вот если у вас:
- адреса офисов фирм.
- адреса торговых точек.
- адреса объектов недвижимости.
- любые адреса в которых могут быть преднамеренные ошибки.
То никакой сторонний сервис не решит проблему поиска по адресам.
А еще у некоторых сторонних сервисов есть жесткие лимиты на количество запросов к геокодеру и конский прайс при превышении лимитов. Не будем называть имен, хотя речь про гугл. Поэтому их данные не всегда возможно использовать даже не для дела, а чисто в справочных целях.
По-нормальному работать с адресами очень тяжело.
что изменится для нас - вебмастеров?
Заблокируют гугл.
Вот как раз с продвижением собственных сервисов в результаты поиска яндекс перебарщивает. В ЕС и США против этого есть антимонопольное законодательство. Но в России оно не работает. Потому никто не будет особо жалеть, если яндекс сосредоточится на поиске и откажется от сервисов.
Никак. Нереально.
А разве сейчас уже нет вот этого правила, с отказом в обслуживании и выводом средств на банковский счет через 180 дней, как было раньше?
Домен madonna*com забрали у бомжа за "недобросовестную конкуренцию" ?
В UDRP там иначе сформулировано. Там не "недобросовестная конкуренция" а "недобросовестные цели". Если еще точнее "bad faith". Это не имеет прямо вот дословного перевода на беларусский язык.
1) добавлять массив доступных объектов каждому юзеру
2) добавлять массив допущенных юзеров каждому объекту.
Как организовать с точки зрения структуры данных вопросов нет. Вопрос как с точки зрения программного кода.
---------- Добавлено 14.10.2019 в 08:13 ----------
Что именно?
На самом деле, когда проверка прав происходит только при попытке выполнить действие над объектом, все просто. Любой из трех методов сгодится. Третий мне понравился с той точки зрения, что не инициализируем лишний код когда не надо.
Но вот есть ситуация: рисуем страничку приложения с объектами, объектов несколько или много. В том случае если у пользователя которому показываем страничку есть право сделать что-то с объектом (редактировать, комментировать, удалить, голосовать, скрыть) к объекту добавляется элемент интерфейса соответствующий. В такой ситуации хочется иметь метод, который отвечает надо или нет добавлять элемент интерфейса, именно у самого объекта. Это логично. Сейчас вот думаю тоже как его реализовать чтобы тоже лишний код не инициализировать когда не надо.
Solmyr, на самом деле, можно любым из вариантов (и их комбинацией) к чему-то интересному прийти.. Главное - начать.. ))
Начато уже давно и давно работает. По третьему методу. Вот именно так как Gerga, говорит, с вспомогательными классами. Но вот при очередных расширениях функционала, стали меня терзать сомнения что это не совсем верно. Сейчас склоняюсь в пользу второго варианта, но пока еще не склонился окончательно. Продумываю разные сценарии. А комбинации и зоопарки методов - это не хорошо. Потом баги стадами ходить будут.
---------- Добавлено 13.10.2019 в 22:53 ----------
Почему нет если:
Потому что фактически один юзер - одна роль. Для каждого юзверя список объектов к которым есть доступ - разный. Причем даже не только просто юзер имеет доступ к своим объектам, а к своим "плюс" - где плюс просто разный список для разных юзеров.
Sirocco, По UDRP такой домен у сквоттера отобрали бы. Так что может быть и по другим мотивам, но беларусское правосудие пришло к тем же выводам что и цивилизованное.