mletov, если ты самозанятый, то у тебя нет постоянного/фиксированного дохода, значит, в этом случае алименты рассчитываются из прожиточного минимума региона.
Роман Юрьевич Ипатьев, в реальной практике не только можно, но и нужно без этого обходиться: пользовательский ввод обязан в данном быть обработанным, т.к. набор полей в каждом случае ограничен и все сводится к простому множественному ветвлению со значением по умолчанию на случай попаданию в систему кулхацкера. Т.е., в самом забавном варианте, если пользователь желает сортировку по полю value1, value2 или value3, то вы не краснея пишете
switch($userRawInput){
case 'value1': $sortField='value1'; break;
case 'value2': $sortField='value2'; break;
case 'value3': $sortField='value3'; break;
default: $sortField='value1';
}
и спокойно спите, не беспокоясь, что кто-то отправит что-то не то. Аналогично с обновлением только заполненных полей или любом другом случае.
topuserman, вообще не вижу никаких проблем в решении вставшей перед вами задачи: выносите каталог на отдельный сервер/кластер в виде независимого сервиса и работаете с ним точно также, как "десятки других интернет-магазинов". Т.е. у вас отдельно будет каталог, отдельно - ваш портал, который с т.з. каталога ничем не отличается от других пользователей. Все.
Что касается ответов на ваши вопросы, то Сергей Горностаев уже написал, где они есть.
Все так, только классу User все связанное с аутентификацией не нужно, это лучше вынести в класс Auth, который будет ей заниматься и извлекать экземпляр User'а для дальнейшей работы или посылать куда положено, если аутентификация или дальнейшая авторизация не прошла.
Gansterito, условный скрипт на питоне, который выполняется где-то и удаленно подключается к SIP-серверу, чтобы скормить ему аудиозапись и получить ответ абонента.
Да, с этим все изначально понятно, спасибо. Непонятно, как это на стороне сервера реализовывают. Нужно написать все это самому, а понимания или знаний не хватает... Сейчас ведь куча всяких сервисов работают с подобными меню. Есть какие-то библиотеки для питона или пхп? Или все зависит от того, какой VoIP используется?
Т.е. сравнивать все-таки придется))) А насчет свойства dirty я вам открою страшную тайну: там тоже происходит сравнение, только его написали за вас. Более того, когда вы его используете, то вам нужно проверить что в нем, а это - еще одно сравнение, внезапно. К тем, что там в недрах объекта производились) Да и не факт, что все делается в Angular или мелкомягком Access'е, и это (либо аналогичное) свойство вам доступно.
Алексей Березников, Я занимаюсь бэкендами, но я вас понял: вы действительно не понимаете о чем идет речь, т.к. ваша область - морды. Если вам действительно необходимо ставить красивые галочки, крестики и вопросики, то абсолютно все равно, что используется - JSON, две модели, записи с признаками или что-то еще - для морды вы получите то, что хватит вам идеально и с запасом. И, во всех случаях nullable - лишнее, если вы уважаете KISS. А вот от сравнений в том или ином виде вы никуда не денетесь, сравнивать придется обязательно. Хотя, может я чего-то не знаю, вы владеете магией и можете узнать одинаковы поля или нет без сравнения?)))
Алексей Березников, Да не нужно ничего сравнивать))) В том-то и дело) То, что я писал про сравнение - это единственно когда оно может понадобиться) А так: сравнение не нужно! Вообще!) Просто прямой, как полет стрелы, update where и все)
Алексей Березников, А тут и спорить не о чем) Поля в случае варианта с двумя моделями сравнивать просто бессмысленно: если что-то в запросе не устраивает модератора, то запрос отклоняется, изменений вообще нет, если устраивает - все кучей обновляется и все - поля везде одинаковы, меняется только содержимое, а выяснять что именно поменялось - тратить время на лишний код для получение бесполезных данных.
Это может быть нужно только для анализа истории изменений, но тогда мы просто берем все записи из PendingProfile + запись Profile и непринужденно получаем искомое. Кстати, случае необходимости ведения истории изменений использовать JSON нельзя, т.к. приведет к лавинообразному нарастанию трудностей на ровном месте, тут подходит только вариант с двумя моделями.
Алексей Березников, Ничего подобного не нужно, эти две модели могут быть абсолютно одинаковы. Если изменения одобряются, то просто нужные данные из PendingProfile обновляют запись целиком в таблице Profile и удаляются в PendingProfile. Если нужна история, то максимум, что будет отличать PendingProfile от Profile - это флаг ожидания модерации. Но можно даже без него обойтись)
Алексей Березников, С JSON - самый простой, самый гибкий - с двумя моделями, там можно легким движением руки добавлять или выпиливать кучи фич разной степени нужности.
V Sh., эти вопросы вообще не вопросы)) Конечно только последний, зачем админу видеть историю правок запроса? Наблюдать, как Пндркй плавно превращался в Андрей, или войну с пальцами за попадание в нужную цифровую клавишу?) Что касается п. 2 - возможность запросить отмену бессмысленна: если изменения внесены, то "по ТЗ" предыдущее состояние никто не помнит, нужно что-то поменять - отправляется новый запрос на изменение. А видит пользователь или нет... По условию сам пользователь запрос и отправляет)
Percivald, он вообще не содержит то, что вы подразумеваете, там - ссылка. Ссылка не меняется, меняется содержимое объекта, на который она показывает. А в момент просмотра содержимое уже изменилось. Вот если написать вызов console.log(planet.innerHTML), то в консоль уйдет не ссылка на объект, а грубо говоря строка. В этом случае вы увидите то, что хотели.
ThunderCat, логично бы было просто сэкономить мое время, пройдя мимо. Или вы себе статистику нарабатываете постя бесполезные посты? Все-таки три поста ни о чем - это вас не лучшим образом характеризует.
То, что вы написали по поводу расхождения цен - предельно очевидно и не стоило вашего времени. Насчет остального - вы ошибаетесь, с момента когда я задал вопрос, один сервис найти все-таки удалось. К сожалению, он, судя по всему, не поддерживается и самые актуальные цены там двухлетней давности.
Сам по себе штрихкод - безусловно) Именно поэтому и интересуют сервисы либо организации, которые владеют информацией по ценам и способны поделиться ей по запросу.