Вряд ли без примера кода кто-то подскажет, какого размера массив вершин, какой код его выводит? Могу предположить, что рисовать лучше в текстуру или непосредственно формами в окно.
FanatPHP, задача не в обработке запроса, а в алгоритмике. Мое мнение, не стоит кичиться и поучать, кто и чего в школе проходил, или не проходил. Ни Вы, ни я, не лучшие специалисты, чтобы бить себя в грудь и шипеть на каждую опечатку или на начинающих разработчиков.
hey_umbrella, либо парсить HTML и доставать ссылки: urllib, BeautifulSoup, либо просто проверяйте наличие документа по дате, с помощью http.client, например (подключились, проверили статус ответа, если 200, значит документ существует). Ссылку можно сгенерировать как строку: '/diff/%s.doc' % date.today().format('%d-%m')
FanatPHP, в данном случае это непринципиально, а предмет отдельной темы. Все предметные области охватить в одном ответе невозможно, и отдельный совет плода не принесет, поскольку контекст неизвестен (есть там у автора validate_concrete_request_schema($_GET) или нет). Это эфемерный пример в порядке ответа на отдельный вопрос. Не рабочий код и не рекомендация по смежным темам.
К слову, 400 уместно для API (не для Ajax-компонент, например), и то, не для всех, даже несмотря на стандарты де-факто (лично я не сторонник обработки исключений в рамках бизнес-логики, порядка try-catch, и даже если это работает в рамках api как then/catch — в некотором смысле это моветон, но с этим приходится мириться, например, в случае RESTful, подходы которого распространились далеко за его рамки) — приложение может быть построено как гипотетически безошибочное, и все аспекты его работы могут рассматриваться как стандартные ситуации. 404, 403, etc — отдельная тема, поскольку по стандарту HTTP означает доступ к ресурсу как таковому, они не призваны обрабатывать ситуации бизнес-логики, на службу к которым поставили другие HTTP-заголовки. И это в общем-то не мое мнение, а давно известная критика использования неприспособленного к таким вещам протокола. Ну, не для этого HTTP создавался и в этом плане устарел. По идее, приложение должно возвращать ресурс, описывающий результат работы как тело, а не смешивать протокол HTTP и бизнес-логику. Тоже самое касается обработки исключений, долгое время считалось паттерном, что приложение не должно содержать исключительных ситуаций, сейчас на это вешают даже валидацию (к примеру), что имхо бред: try { $validator->check() } catch (ValidationException ...) { response(400); }
hey_umbrella, так у Вас проблема в парсинге самого doc-файла? Или в поиске ссылок на странице? Да и судя по паттерну названия файла, это день-месяц, можно и без разбора страницы обойтись, а сразу пытаться подгрузить файл вида: url-to-resource/diff/DD-MM.doc
FanatPHP, какой скрипт, по-хорошему? И что значит, по-хорошему?
Будет полной дурью, если пишете микросервис — делать проверки через прослойки, вместо прямого и простого сведения типа. Если повышать уровень до масштабируемых приложений, то тут в мире PHP не слишком много хороших решений. Я бы писал слой моделей с автоматизацией, для перехвата запроса через промежуточный уровень, чтобы до момента действия не дошло, если данные неверны. Ну или хотя бы описанная схема данных, а не бытовуха уровня "валидации форм". Но надо все же понимать, что ситуации разные, задача, в которой вопрос по алгоритму, в котором фигурирует ошибочное $_GET и вообще заведомо неверное решение непонятного контекста, не нужно изобретать лишних сущностей. Здесь человек еще даже не PHP изучает, а пытается управлять данными как таковыми. Но опять-таки, в зависимости от ситуации intval — нормальное решение. В данном случае гарантирует правильное сравнение в эфемерном примере.
FanatPHP, а, да, не str, поправил, это опечатка, т.к. работаю на 5-6 языках в стеке и все реже с PHP. Спасибо за замечание. Я так понял, человеку нужна строка, но это непринципиально в данном случае.
necrodeflorator, в GET может прийти все что угодно, валидация — это отдельная задача, в любом случае, во многих ситуациях достаточно привести к целому. В данном случае, задачи вообще никакой не стоит. Просто замена сравнения строк с примером. Если бы человек попросил упростить:
FanatPHP, ну неточность допустил только в 3-м варианте, дописал в спешке по Вашему замечанию. В остальном, если intval пропустит число, то результат верный.
С++ сейчас в спорном положении, не мало полемики вокруг стандартов, что-то может и назреть. В этом плане C пока еще жив, да и слишком распространен, чтобы быть потесненным. А альтернативой выступает разве что Rust (попав, например, первым после С/++ в ядро Linux). Java и C# немного из другой ниши.
postya, если у Вас есть компонент со свойствами, то при обращении к component.property Vue прозрачно подставляет поля из data {} — наблюдаемых свойств, и props {} — наблюдаемых входных параметров. Соответственно они должны иметь разные имена data { property: 123 } , props { property: 123 } — ошибка. Ведь для component.property — поле property дублируется. Это в документации хорошо описано, стоит прочитать ее всю от корки до корки.
Так Rsa97 не наводку дал, а ответ, явно указав, что данные (data) компонента перекрывают его входные данные (props). Его ответ — решение Вашей проблемы. "Благодаря наводке" : )
И еще, input1, input2 — старайтесь сразу давать осмысленные имена полям. Это еще не раз аукнется в будущем.
