селекты то как раз удобней не стали :) но и не сильно усложнились, в следующей статье будут примеры использования с вычислением параметров поиска и с собственно поиском, плюс выдача Значений Характеристик для конкретной Сущности, остальные вещи вроде тривиальные, короче будут примеры, куда же без них.
90-е без Старкрафта и без Героев Меча и Магии? я не знаю как во всём мире но в России нет людей ( компьютеро играющих ) которым бы эти названия ни чего не говорили.
таланты они ищут, и для таланта всегда найдут работу, то что у какой то компании позиции всегда открыты означает только, то что компания готова к инвестициям в людей и новые проекты.
у Гугла поисковая выдача заточена под пользователя, у когото это первая десятка записей, у кого то не первая, я по jQuery раз в пол года ищу, у меня всякая фигня в первой десятке.
Вот как раз не объясняете, а говорите «я не знаю» и «я не разобрался».
статья про работу с API, как работать с API я разобрался.
То, что кто-то решил исправить ошибки, не означает, что надо писать плохие статьи. Особенно они вредны для новичков, которые не всегда могут разобраться, что там правильно, а что нет.
Пишите хорошие, а то приходиться писать плохие — свято место пусто не бывает :))
Для статьи код можно было причесать, при ее написании вас никто не торопил
мои обстоятельства меня торопили, на статью ушло около 4-х часов, это пол воскресения, а ещё надо был она работе выправить ножки на материнке, в подъезде организовать установку замка на чёрный ход в подъезд и вообще могу я в воскресение отдаться безделью?
Тут достаточно уметь гуглить, «jquery select by name» и «jquery get id attribute». Хотя не вижу принципиальных отличий от ваших селекторов.
принципиальное отличие межу мои и вашим вариантами только в опыте автора решения в использовании jquery
Если вы не знаете PHP и jQuery, зачем тогда писать обучающие статьи
«на пять не знает даже Бог», если что. Код решает задачу, и я в статье объясняю технологию решения, чем не обучение, учу плохому? вы внесли свою лепту что бы статья стала учить хорошему :)
отличается, в контрагентах из полученного массива сохраняются только 'rows', в номенклатурах такой обработки нет, она идёт снаружи метода.
var organization = $('#orderForm :input:radio:checked[name=organization]').attr('id');
мне бы ваши познания в jquery :)
Вам сложно будет пройти тестовое задание с таким подходом. Никому неохота разбираться в особеностях названий чужого кода
у этого тестового была цель выполнить в оговоренный срок, а не качественно написать, у меня отведённое время ушло на «борьбу» с PHP по обработке $_POST, от которой пришлось отказаться и на работу с jquery, на то что бы причесать код времени не осталось
задание принимал бизнес-аналитик / проджект менеджер который собирает команду фрилансеров, ему в срок важнее, качества кода он не оценит.
ну вот я её и решил не тратя время на изучение тех вещей которые уже работают, в этом задании у меня был затык с фронт-эндом, плюс PHP за каким то чёртом заменяло пробелы на нижнее подчёркивание, вот это был ад, аж пришлось запариться на input:radio.
$сounterparty это массив, а название в единственном числе
— я устал от множественных чисел, приписок array collection list и т.п., больше не практикую.
Зачем вы пишете разметку в строках? Вам лень тег php закрыть?)
видимо
Потенциальная XSS-уязвимость. Что если кто-нибудь заведет контрагента с названием ""?
контрагентов заводит владелец аккаунта, хочет себе в ногу выстрелить — сколько угодно, хотя я думаю разработчики API такую возможность уже исключили
Зачем вы отправляете массив, если вам нужен только первый элемент?
если всё можно обработать по одной технологии то зачем придумывать две? я ни когда не ставлю перед собой цели оптимизации с выгадыванием миллисекунд
Вот и ваша проблема с POST. PHP не принимает данные в формате JSON (документация). Надо убрать contentType, jQuery сам подставит правильный, данные отправлять через $('#orderForm').serialize(), и поменять обработку на сервере, потому что данные сериализуются немного в другом формате.
спасибо огромное, за это вам можно все наезды простить :)
Работа функции getNomenclature() не соответствует названию
соответствует, предполагалось, что вернётся чёрти что и это надо будет как то парсить, но во всех трёх случаях и с организацией и с контрагентами и с номенклатурой всё оказалось намного проще, можно было конечно из API_шного ответа выдирать только айдишник и имя, пихать их в массив и его возвращать, но для меня этот проект был почеркушкой а не фундаментом для дальнейшей разработки и ваш серьёзный подход это просто последующие итерации которые происходят, тогда когда они нужны, в данном случаи они были не нужны.
От нечего делать сделал небольшой рефакторинг этого задания
спасибо, ваш разбор полётов был одной из целей этой публикации
в работе не надо разрабатывать то что кто то уже разработал, не надо тратить время на то что бы разобраться с чужим кодом, если этот код работает без нареканий, надо тратить время на решение задач а не на проверку «инструментов», если что то работает, то надо этим пользоваться, а не разбирать по винтикам, что бы удостовериться что все винтики живые, ни один не разболтался и резьба ни где не сорвана. Разработка это умение комбинировать инженерные решения, а не умение потратить рабочее время на изобретение велосипеда.
мои статьи по SQL набирали 6к/9к/5к просмотров, у этой статьи всего 1.7к, не очень то люди и заметили, а кто заметил, тот влепил минус — как это принято ни кто не смотрел исходники выложенные на гите, и приняли код приведённый в статье за чистую монету, отсюда эти… не обоснованные обвинения в «лапше», в проекте вообще 4 файла:
moysklad_routine_library — планировалась библиотека функций, по факту вышло что можно было обойтись всего тремя, хотя они общие для клиентской и серверной части, так что всё равно надо было выносить в отдельный файл.
moysklad_customer_order — клиентская часть — смесь модели и фронтэнда, мне кажется для одностраничного сайта вполне допустимо, при чём файл явно делитьсян а две части — сначала PHP с подготовкой данных, затем html с выводом — «смешение» php c html чисто формальное.
moyskald_add_order — серверная часть.
moysklad_curl_details — файл с параметрами API и аутентификации.
на мой вкус мухи отдельно, котлеты отдельно.
но у людей голова ломается от отсутствия классов, от отсутствия автозагрузчика, видимо когда то им за это хорошенько досталось и теперь они комплексуют, хорошо хоть не обвинили в отказе от фремворка.
Единственный человек по делу написал это ilyaplot — ещё раз спасибо.
Очень жаль что ни кто не прокомментировал проблему с пустым POSTом но «полным» — php://input
такое резюме по отклику на статью.
ЗЫ
нет что бы поржать вместе со мной, зачем то обосрали, видимо потребность в «срать» имеет приоритет над «ржать» :)
главное код тестами покрыть :) а когда нет тестов, то живые пользователи тоже сгодятся, но в этом случае важно успеть накатить бэкап раньше чем пользователю прочухают в чём дело: )
я бы подобные статьи с удовольствием читал если бы их кто то их писал, особенно я был бы рад им в поисковой выдаче Google, это лучше чем изобретать очередной велосипед, но мало кто такие элементарные вещи разжёвывает, потому что всем и так всё ясно.
схалявить и зафигачить JSON без json_encode, тупо вклеить
если следовать принципу Keep It Simple Stupid — тупо текст из документации к API это проще чем генерация этого текста.
Хотя генерация конечно методологически надёжней, но документация API после публикации не поменяется.
принцип You ain't gonna need it говорит о выполнении необходимого минимума действий для достижения цели. Если модификация не предполагается, то «статичный» текст полностью удовлетворяет «условиям задачи»
колонку такую можно сделать, но в IDE она будет выделяться другим светом как ключевое слово, мне так не удобно
селекты то как раз удобней не стали :) но и не сильно усложнились, в следующей статье будут примеры использования с вычислением параметров поиска и с собственно поиском, плюс выдача Значений Характеристик для конкретной Сущности, остальные вещи вроде тривиальные, короче будут примеры, куда же без них.
такого бизнес требования не было, прикрутить не сложно
у Гугла поисковая выдача заточена под пользователя, у когото это первая десятка записей, у кого то не первая, я по jQuery раз в пол года ищу, у меня всякая фигня в первой десятке.
статья про работу с API, как работать с API я разобрался.
Пишите хорошие, а то приходиться писать плохие — свято место пусто не бывает :))
мои обстоятельства меня торопили, на статью ушло около 4-х часов, это пол воскресения, а ещё надо был она работе выправить ножки на материнке, в подъезде организовать установку замка на чёрный ход в подъезд и вообще могу я в воскресение отдаться безделью?
принципиальное отличие межу мои и вашим вариантами только в опыте автора решения в использовании jquery
«на пять не знает даже Бог», если что. Код решает задачу, и я в статье объясняю технологию решения, чем не обучение, учу плохому? вы внесли свою лепту что бы статья стала учить хорошему :)
отличается, в контрагентах из полученного массива сохраняются только 'rows', в номенклатурах такой обработки нет, она идёт снаружи метода.
мне бы ваши познания в jquery :)
у этого тестового была цель выполнить в оговоренный срок, а не качественно написать, у меня отведённое время ушло на «борьбу» с PHP по обработке $_POST, от которой пришлось отказаться и на работу с jquery, на то что бы причесать код времени не осталось
задание принимал бизнес-аналитик / проджект менеджер который собирает команду фрилансеров, ему в срок важнее, качества кода он не оценит.
видимо
контрагентов заводит владелец аккаунта, хочет себе в ногу выстрелить — сколько угодно, хотя я думаю разработчики API такую возможность уже исключили
если всё можно обработать по одной технологии то зачем придумывать две? я ни когда не ставлю перед собой цели оптимизации с выгадыванием миллисекунд
спасибо огромное, за это вам можно все наезды простить :)
соответствует, предполагалось, что вернётся чёрти что и это надо будет как то парсить, но во всех трёх случаях и с организацией и с контрагентами и с номенклатурой всё оказалось намного проще, можно было конечно из API_шного ответа выдирать только айдишник и имя, пихать их в массив и его возвращать, но для меня этот проект был почеркушкой а не фундаментом для дальнейшей разработки и ваш серьёзный подход это просто последующие итерации которые происходят, тогда когда они нужны, в данном случаи они были не нужны.
спасибо, ваш разбор полётов был одной из целей этой публикации
на мой вкус мухи отдельно, котлеты отдельно.
но у людей голова ломается от отсутствия классов, от отсутствия автозагрузчика, видимо когда то им за это хорошенько досталось и теперь они комплексуют, хорошо хоть не обвинили в отказе от фремворка.
Единственный человек по делу написал это ilyaplot — ещё раз спасибо.
Очень жаль что ни кто не прокомментировал проблему с пустым POSTом но «полным» — php://input
такое резюме по отклику на статью.
ЗЫ
нет что бы поржать вместе со мной, зачем то обосрали, видимо потребность в «срать» имеет приоритет над «ржать» :)
если следовать принципу Keep It Simple Stupid — тупо текст из документации к API это проще чем генерация этого текста.
Хотя генерация конечно методологически надёжней, но документация API после публикации не поменяется.
принцип You ain't gonna need it говорит о выполнении необходимого минимума действий для достижения цели. Если модификация не предполагается, то «статичный» текст полностью удовлетворяет «условиям задачи»