Записать данные json в переменную
Нужно загрузить json и записать его данные в переменную, что бы я смог вытаскивать разную информацию из переменной в любой момент. Не могу понять как это сделать!
Отслеживать
задан 5 апр 2020 в 13:06
олег логвинов олег логвинов
39 7 7 бронзовых знаков
4 ответа 4
Сортировка: Сброс на вариант по умолчанию
var test = JSON.parse( data ); И консоль должна быть внутри success, а не под запросом, потому что запрос не синхронный
Отслеживать
ответ дан 5 апр 2020 в 13:08
user347472 user347472
В том то и дело, мне нужно данные забрать из success и использовать их вне ajax
5 апр 2020 в 13:11
JavaScript так не работает. Если код стал асинхронным, то его уже нельзя привести в синхронный вид. Так что у вас либо всё далее будет идти в другой функции а не снизу, либо как вариант через async-await через промисы, но там тоже только видимость синхронности.
– user347472
5 апр 2020 в 13:13
Т.к. ajax — асинхронная операция, то она может длиться и 2 секунды и 22 секунды, хотя в это время может и страницу прогрузиться и пользователь что-то понажимать.
Если я правильно разглядел, то никакая работа не предполагается, пока не будет загружен json . Отсюда есть минимум один выход: вешать картинку «loading» перед запросом и убирать после получения ответа. Можно это сделать на весь экран, чтоб пользователь ничего не трогал.
let test = null; $.ajax(< url: 'http://atom-web.github.io/wattson/style-components/sity.json', beforeSend: function( xhr ) < // Здесь включаем какой-то loader.gif чтобы дать пользователю понять, // что идёт загрузка данных >, success: function(data)< test = data; // Здесь выключаем loader.gif и разблокируем элементы, // чтобы пользователь мог начать работать >, >); Также можно обратить внимание на async/await функции, что позволит дождаться загрузки аякса и тоже выполнять функции далее.
Чтение и запись в файл JSON-объекта
Эта статья научит вас парсить данные из JSON. Также вы узнаете, как читать и записывать в файл данные JSON.
За последние 5-10 лет формат JSON был одним из самых популярных способов сериализации данных (если не самым популярным). Особенно в веб-разработке. С этим форматом вы столкнетесь при работе с REST API, конфигурациями приложений или базами данных.
Несомненно, знать принципы работы JSON — очень важно. В какой-то момент вы обязательно с ним встретитесь. Возможно, вы захотите узнать, как читать и записывать JSON в файл. Все эти действия — очень простые. В этом вы убедитесь, разобрав следующие примеры.
Запись JSON в файл
Самый простой способ записать JSON в файл — использовать словарь. Они могут хранить вложенные словари, массивы, булевы значения и другие типы данных вроде целых чисел и строк. Более детальный список поддерживаемых типов данных можно найти здесь.
Во встроенной библиотеке json есть «волшебный» метод, который позволяет конвертировать словари в сериализованную JSON-строку.
import json data = <> data['people'] = [] data['people'].append(< 'name': 'Scott', 'website': 'pythonist.ru', 'from': 'Nebraska' >) data['people'].append(< 'name': 'Larry', 'website': 'pythonist.ru', 'from': 'Michigan' >) data['people'].append(< 'name': 'Tim', 'website': 'pythonist.ru', 'from': 'Alabama' >) with open('data.txt', 'w') as outfile: json.dump(data, outfile)
После импорта библиотеки json мы объявляем несколько словарей и наполняем их данными. Самая важная часть — в конце программы. Здесь мы используем оператор with , чтобы открыть файл. После этого мы используем метод json.dump , чтобы записать наши словари в файл.
Вторым аргументом может быть любой файлоподобный объект — даже если это не совсем файл. Например, сокет. Его можно открыть, закрыть и записать так же, как и файл. С подобным вариантом использования JSON вы точно столкнетесь — это важно запомнить.
Стоит упомянуть и о вариации метода json.dump — json.dumps . Этот метод позволяет вернуть JSON-строку, а не записывать ее в файл. Это может быть полезно, если вы хотите изменить JSON-строку. (например, зашифровать)
Чтение JSON из файла
Чтение JSON из файла такое же простое, как и запись. С помощью библиотеки json мы можем спарсить JSON-строку прямо из файла. В этом примере мы парсим данные и выводим их в консоль:
import json with open('data.txt') as json_file: data = json.load(json_file) for p in data['people']: print('Name: ' + p['name']) print('Website: ' + p['website']) print('From: ' + p['from']) print('')
json.load — очень важный метод, запомните его. С его помощью происходит чтение файла, парс JSON-данных. После этого все данные записываются в словарь и возвращаются вам.
Как и у json.dump , у json.load есть дополнительный метод. Он позволяет работать со строками напрямую, ведь чаще всего у вас не будет файлоподобного объекта, содержащего JSON. Как вы уже догадались, называется он json.loads . Допустим, вы вызываете конечную точку REST с помощью GET, который возвращает строку. Ее мы и можем напрямую передать в json.loads .
Параметры
При сериализации данных в JSON могут возникнуть проблемы. Например, его будет не очень удобно читать, ведь удаляются все пробелы. В большинстве случаев этот вариант вполне хорош, но порой нужно внести небольшие изменения. К примеру, добавить пробелы, чтобы JSON было удобнее читать. У json.load и json.dump есть несколько параметров, которые дают необходимую гибкость. О некоторых из них мы и поговорим.
Pretty-Printing
Сделать JSON более удобочитаемым (pretty-printing) — очень просто. Нужно лишь передать целое число в параметр indent :
import json data = <'people':[<'name': 'Scott', 'website': 'pythonist.ru', 'from': 'Nebraska'>]> json.dumps(data, indent=4) < "people": [ < "website": "pythonist.ru", "from": "Nebraska", "name": "Scott" >] >
Это довольно полезно. Особенно если вам часто приходится читать JSON во время работы. Также вы можете использовать использовать команду json.tool прямо в командной строке. Если вы хотите удобочитаемый JSON, наберите в командной строке следующий код:
$ echo '<"people":[<"name":"Scott", "website":"pythonist.ru", "from":"Nebraska">]>' | python -m json.tool < "people": [ < "name": "Scott", "website": "pythonist.ru" "from": "Nebraska", >] >
Сортировка
В JSON объект определяется следующим образом:
Объект — это неупорядоченный набор пар ключ/значение.
То есть, порядок не гарантируется. Но навести его реально. Сделать это можно с помощью передачи True в параметр sort_keys в методах json.dump или json.dumps .
import json data = <'people':[<'name': 'Scott', 'website': 'pythonist.ru', 'from': 'Nebraska'>]> json.dumps(data, sort_keys=True, indent=4) < "people": [ < "from": "Nebraska", "name": "Scott", "website": "pythonist.ru" >] >
ASCII-текст
По умолчанию json.dump проверяет, имеет ли ваш текст в словаре кодировку ASCII. Если присутствуют символы, отличные от ASCII, они автоматически экранируются. Это показано в следующем примере:
import json data = jstr = json.dumps(data, indent=4) print(jstr)
Но это не всегда приемлемо. Во многих случаях вы бы хотели сохранить символы Unicode нетронутыми. Для этого нужно передать в параметр ensure_ascii значение False .
jstr = json.dumps(data, ensure_ascii=False, indent=4) print(jstr)
Данные, которые вводятся через input с использованием vue js
Здравствуйте,возник вопрос, я ввожу данные через input , потом эти данные «реактивно»(если не ошибся в терминологии) отображаются на сайте, то есть ввожу и они сразу отображаются , я их ввел , а где эти самые строки хранятся? Мне нужно эти вводимые данные отправлять на сервер , но отправляется пустые строки.
Мой план действий:
1)определить, где хранятся данные;
2)потом через fetch js отправить их на сервер;
Нужно лишь узнать, где хранятся данные, вводимые с помощью vue.
Лучшие ответы ( 1 )
| Здесь вы можете заказать любую студенческую или школьную работу. |
94731 / 64177 / 26122
Регистрация: 12.04.2006
Сообщений: 116,782
Ответы с готовыми решениями:
Данные которые вводятся в табоицу в команднйо строке
Ребята как создать такую таблицу скажем с4 колонками ну и соответсвенно ввести и обработать данные.
Что нужно сделать, чтобы данные, которые вводятся в поля формы, стирались сами
Private Sub Кнопка14_Click() Set nabor = CurrentDb.OpenRecordset("Студенты") With nabor .Addnew.
Записать по порядку числа в массив, которые вводятся через пробел
вводится: В первую строчку вводится число N – количество камней Во вторую строчку вводится N.
Сколько различных символов Данные вводятся с клавиатуры или из файла input.txt, выводятся на экран или в файл output.txt
Ограничение по времени, сек 2 Ограничение по памяти, мегабайт 64 Напишите программу, которая.
800 / 583 / 207
Регистрация: 21.02.2019
Сообщений: 2,095
.. данные обычно хранятся в массивах/объектах, либо в самом компоненте, либо в store (если используется vuex) . а передаются в компоненты через props . т.е. надо смотреть в декларации data <>.
Регистрация: 30.04.2020
Сообщений: 42
хорошо,я разобрался с тем, в каких переменных хранятся данные, а как мне эти данные отправлять на сервер? Может есть статья, где примерно это описано.
Или вы вкратце объясните, если есть такая возможность, конечно.
Всегда онлайн
1084 / 788 / 295
Регистрация: 07.04.2013
Сообщений: 2,703
AmanShygaibaev, пример вашего Vue компонента / экземпляра.
input type="text" placeholder="some user input" v-model="user_input"> button @click="sendData">Send data/button>
1 2 3 4 5 6 7 8 9 10 11 12
{ data() { return { user_input: null } }, methods: { sendData() { fetch(`myserver.com/api/some_action/${this.user_input}`); //ваш код работы с сервером } } }
Есил ввести в поле «Hello», и нажать на кнопку то будет сделан запрос GET myserver.com/api/some_action/Hello. Надеюсь суть уловили.
К счастю, в Vue хорошая документация, ознакомтесь: https://ru.vuejs.org/v2/guide/index.html
Регистрация: 30.04.2020
Сообщений: 42
Я немного не понял как работает 9 строка кода js , я понял , что отправляется запрос через GET , потом API, а после уже пойдет php файл обработчик? Я имею ввиду , как эти данные записывать в mySQL? И вроде бы не получится отправлять через GET массив данных.
Код ниже создает блок (может несколько), куда можно будет вписывать и/ф студентов, где эти данные в vue хранятся, я вроде понял, а как их отправлять в mySQL, еще возник вопрос с указателем this , на случай, если блоков больше одного, то как данные в таком случае отправлять? Vue же, как я понимаю, будет отправлять данные только последнего объекта(так как на него указывает this)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51
const app = new Vue({ el: "#app", data:{ quadro: {"title": "Введите необходимый курс"}, cards: [], newCardName: "", //название группы mover: false, movedTarefa: {}, movedCard: {}, qualTarefaMover: {}, idCard: 0, idTarefa: 0, minif: false, editQuadroTitle: false }, mounted(){ this.montar() }, methods:{ newCard(){ if(!this.newCardName == ''){ this.cards.push({ "id": this.cards.length, "name": this.newCardName, //название группы, которое вписывается через input "tarefas" : [], "novaTarefa": null, "icon": "fas fa-clipboard-list", "delete": true, "edit": false }) this.newCardName = "" } }, newTarefa(card){ // блок с и/ф студента const id = this.cards.indexOf(card) var finalizadoT = false if(card.id === 0 ){ finalizadoT = true } if(!this.cards[id].novaTarefa == ''){ this.cards[id].tarefas.push({ "id": this.cards[id].tarefas.length, "name": this.cards[id].novaTarefa, "finalizado" : finalizadoT, "moved": false }) this.cards[id].novaTarefa = "" } },
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
form onkeydown="return event.key != 'Enter'" id="send" method="POST" action="data.php"> input type="text" v-model="card.novaTarefa" v-on:keyup.enter="newTarefa(card)" placeholder="Введите и/ф студента" maxLength="100" name="studentname"> /form> /div> div class="card"> h1>Создание группы/h1> form id="send" onkeydown="return event.key != 'Enter'" method="POST" action="data.php"> input id="inputList" type="text" v-model="newCardName" v-on:keyup.enter="newCard" placeholder="Введите название группы" maxLength="30" name="group" > /form>
Принципы построения REST JSON API
Эта памятка писалась для внутренних нужд (открыть глаза менее опытным в вебе коллегам). Но, т.к. я насмотрелся велосипедов от довольно уважаемых, казалось бы, контор, — выкладываю на хабр. Мне кажется, многим будет полезно.
Зачем
Надеюсь, читающий уже понимает, зачем ему вообще нужен именно REST api, а не какой-нибудь монстр типа SOAP. Вопрос в том, зачем соблюдать какие-то стандарты и практики, если браузеры вроде бы позволяют делать что хочешь.
- Стандарт HTTP это стандарт. Его несоблюдение вредно для кармы и ведёт к постоянным проблемам с безопасностью, кэшированием и прочими «закидонами» браузеров, которые совсем не закидоны, а просто следование стандарту.
- Велосипеды со всякими невозможно нормально тестировать и отлаживать
- Поддержка большим количеством готовых клиентских библиотек на все случаи жизни. Те, кто будет вашим api пользоваться, скажут большое человеческое спасибо.
- Поддержка автоматизированного интеграционного тестирования. Когда сервер на любые запросы отдаёт 200 ОК — ну, это такое себе развлечение.
Структура запросов и ответов
Любой http-запрос начинается со строки
где METHOD — это метод доступа (GET, PUT и т.д.), а URI — адрес запрашиваемого ресурса.
В начале запроса идут заголовки — просто текстовые строки вида key: value
Затем передаётся пустая строка, означающая конец секции заголовков, и затем — тело запроса, если оно есть.
В ответе сначала передаётся строка с версией http, кодом и строковым статусом ответа (например HTTP/1.1 200 OK ), далее текстовые заголовки ответа, потом пустая строка, потом тело ответа.
Тут вроде всё просто.
Кодирование запросов и ответов
Кодировка для всех и запросов, и ответов — UTF-8 и только UTF-8, т.к. некоторые, кхм, «браузеры» имеют привычку игнорировать содержимое заголовка charset.
Использование кодов символов и html-сущностей не допускается, т.е. режим JSON_UNESCAPED_UNICODE обязателен. Не все клиенты знают всю таблицу html сущностей (типа каких-нибудь ù ), да и при чём тут html. Не все клиенты готовы/хотят заниматься перекодированием \uXXXX; и &#XX;. Плюс возможны «весёлые» ситуации с избыточным экранированием или пропаданием слэшей и амперсандов.
Все данные, кроме URI и двоичных файлов, передаются в формате JSON. Обратите внимание, что далеко не всякий валидный javascript код является валидным JSON.
В частности, для строк используются только двойные кавычки. Одинарные кавычки в json-данных, хотя и допустимы в «обычном» javascript, могут вызвать непредсказуемые плохо отлавливаемые баги.
В запросах обязательно указывается заголовок
Accept: application/json, */*; q=0.01Вызовы к API отличаются от прочих вызовов (например, обычной загрузки html страницы по данному URI) именно по наличию application/json в Accept.
Сама строка Accept формируется браузером/клиентом и может немного отличаться от браузера к браузеру, например, наличием и других форматов типа text/javascript , поэтому нужно проверять не равенство, а именно вхождение «application/json».
В ответах 2хх с непустым телом обязательно наличие заголовка ответа
Content-Type: application/json; charset=UTF-8При наличии тела запроса также обязателен заголовок запроса
Content-Type: application/json; charset=UTF-8либо, при загрузке файлов,
Content-Type: multipart/form-dataи далее, в первой части
----------------- Content-Type: application/json; charset=UTF-8 Content-Disposition: form-data; name="data"после чего для каждого файла
----------------- Content-Type: image/jpeg Content-Disposition: form-data; name="avatar"; filename="user.jpg"Если вы используете защиту от CSRF (а лучше бы вам её использовать), то удобнее передавать CSRF-токен в отдельном заголовке (типа X-CSRF-Token) для всех запросов, а не внедрять вручную в каждый запрос. Хранить CSRF токен в куках плохо по той причине, что куки можно украсть, в чём собственно и состоит суть CSRF атаки.
Структура URI
Нагородить можно всякое, но лучшая практика — чтобы все URI имели вид
ну, или если у вас api лежит в какой-то папке,
- entity — название сущности, например, класса или таблицы/представления в БД. Примеры: users , dictionary
- idopt. — первичный ключ объекта. Если первичный ключ составной, то части указываются через слэш. Примеры: /users/10 , /dictionary/ru/apptitle
- paramsopt. — дополнительные параметры выборки для списочных запросов (фильтрация, сортировка, паджинация и пр.). Форматируются по правилам HTTP GET параметров (функции encodeURIComponent и пр.)
Для разбора части URI до знака вопроса можно использовать регулярку
#^/(([a-z]\-_)+)/?(([a-z][A-Z][0-9]\-_/)*)?$#Ведущий слэш обязателен, т.к. неизвестно, с какого URL будет осуществлён запрос.
Методы HTTP
GET /:entity/:id — getById
В случае успеха сервер возвращает 200 OK с полями объекта в формате JSON в теле ответа (без дополнительного оборачивания в какой-либо объект)
В случае, если объект с такими id не существует, сервер возвращает 404 Not Found
В ответе обязательно должны быть заголовки, касающиеся политики кэширования, т.к. браузеры активно кешируют GET и HEAD запросы. При остутствии какой-либо политики управления кэшем должно быть:
Cache-Control: no-store, no-cache, must-revalidate Pragma: no-cacheGET /:entity[?param1=. ¶m2=. ] — списочный get
Простой случай: в случае успеха сервер возвращает 200 OK с массивом объектов в формате JSON в теле ответа (т.е. ответ начинается с [ и заканчивается ] ).
Если массив получился пустой, всё равно вовзращается 200 OK с пустым масивом [] в теле ответа.
Более сложный вариант: возвращается объект, в одном из полей которого — искомый массив. В остальных полях — данные о пагинации, фильтры, счётчики и пр. Только держите это консистентным по всем api.
HEAD /:entity[/:id] — запрос заголовков
Полный аналог GET с таким же URI, но не возвращает тело ответа, а только HTTP-заголовки.
Реализация поддержки HEAD запросов веб-сервером обязательна.
Активно используется браузерами в качестве автоматических pre-flight запросов перед выполнением потенциально опасных, по их мнению, операций. Например, браузер Chrome активно кидается head-запросами для получения политик CORS при кросс-доменных операциях (виджеты и пр). При этом ошибка обработки такого head-запроса приведёт к тому, что основной запрос вообще не будет выполнен браузером.
Может использоваться для проверки существования объекта без его передачи (например, для больших объектов типа мультимедиа-файлов).
POST /:entity — создаёт новый объект типа :entity
В теле запроса должны быть перечислены поля объекта в формате JSON без дополнительного заворачивания, т.е.
В случае успеха сервер должен возвращать 201 Created с пустым телом, но с дополнительным заголовком
указывающим на месторасположение созданного объекта.
Возвращать тело ответа чаще всего не требуется, так как у клиента есть все необходимые данные, а id созданного объекта он может получить из Location.
Также метод POST используется для удалённого вызова процедур (RPC), в этом случае ответ будет иметь статус 200 OK и результаты в теле. Вообще смешивать REST и RPC в одном api — идея сомнительная, но всякое бывает.
Единственный неидемпотентный некешируемый метод, т.е. повтор двух одинаковых POST запросов создаст два одинаковых объекта.
PUT /:entity/:id — изменяет объект целиком
В запросе должны содержаться все поля изменяемого объекта в формате JSON.
В случае успеха должен возвращать 204 No Data с пустым телом, т.к. у клиента есть все необходимые данные.
Идемпотентный запрос, т.е. повторный PUT с таким же телом не приводит к каким-либо изменениям в БД.
PATCH /:entity/:id — изменяет отдельные поля объекта
В запросе должны быть перечислены только поля, подлежащие изменению.
В случае успеха возвращает 200 OK с телом, аналогичным запросу getById, со всеми полями изменённого объекта.
Используется с осторожностью, т.к. два параллельных PATCH от двух разных клиентов могут привести объект в невалидное состояние.
DELETE /:entity/:id — удаляет объект, если он существует.
В случае успеха возвращает 204 No Data с пустым телом, т.к. возвращать уже нечего.
Идемпотентный запрос, т.е. повторный DELETE с таким же адресом не приводит к ошибке 404.
OPTIONS /:entity[/:id]
Получает список методов, доступных по данному URI.
Сервер должен ответить 200 OK с дополнительным заголовком
Allow: GET, POST, . Некешиуремый необязательный метод.
Обработка ошибок
Возвращаемые ошибки передаются с сервера на клиент как ответы со статусами 4хх (ошибка клиента) или 5хх (ошибка сервера). При этом описание ошибки, если оно есть, приводится в теле ответа в формате text/plain (без всякого JSON). Соответственно, передаётся заголовок ответа
Content-Type: text/plain; charset=UTF-8Использовать html для оформления сообщений об ошибках в api — так себе идея, будут проблемы журналированием и т.д. Предполагается, что клиент способен сам красиво оформить сообщение об ошибке для пользователя.
При выборе конкретных кодов ошибок не следует слишком увлекаться и пытаться применить существующие коды только потому, что название кажется подходящим. У многих кодов есть дополнительные требования к наличию определённых заголовков и специальная обработка браузерами. Например, код 401 запускает HTTP-аутентификацию, которая будет странно смотреться в каком-нибудь приложении на react или electron.
UPD по мотивам комментариев. Клиенты у вас будут разные: не только веб и мобильные приложения, но и такие штуки, как запускалка интеграционных тестов (CI), балансировщик нагрузки или система мониторинга у админов. Использование или неиспользование того или иного статуса ошибки определяется тем, будет ли он полезен хоть какому-то клиенту (т.е. этот клиент сможет предпринять какие-то действия конкретно по этому коду) и, наоборот, не будет ли проблем у какого-то из клиентов из-за неиспользования вами этого кода. Придумать реальный use-case, когда реакция клиента будет различаться в зависимости от 404 или 410, довольно сложно. При этом отличий 404 от 200 или 500 — вагон и телега.
400 Bad Request
Универсальный код ошибки, если серверу непонятен запрос от клиента.
403 Forbidden
Возвращается, если операция запрещена для текущего пользователя. Если у оператора есть учётка с более высокими правами, он должен перелогиниться самостоятельно. См. также 419
404 Not Found
Возвращается, если в запросе был указан неизвестный entity или id несуществующего объекта.
Списочные методы get не должны возвращать этот код при верном entity (см. выше).
Если запрос вообще не удалось разобрать, следует возвращать 418.
415 Unsupported Media Type
Возвращается при загрузке файлов на сервер, если фактический формат переданного файла не поддерживается. Также может возвращаться, если не удалось распарсить JSON запроса, или сам запрос пришёл не в формате JSON.
418 I’m a Teapot
Возвращается для неизвестных серверу запросов, которые не удалось даже разобрать. Обычно это указывает на ошибку в клиенте, типа ошибки при формировании URI, либо что версии протокола клиента и сервера не совпадают.
Этот ответ удобно использовать, чтобы отличать запросы на неизвестные URI (т.е. явные баги клиента) от ответов 404, у которых просто нет данных (элемент не найден). В отличие от 404, код 418 не бросается никаким промежуточным софтом. Альтернатива — использовать для обозначения ситуаций «элемент не найден» 410 Gone , но это не совсем корректно, т.к. предполагает, что ресурс когда-то существовал. Да и выделить баги клиента из потока 404 будет сложнее.
419 Authentication Timeout
Отправляется, если клиенту нужно пройти повторную авторизацию (например, протухли куки или CSRF токены). При этом на клиенте могут быть несохранённые данные, которые будут потеряны, если просто выкинуть клиента на страницу авторизации.
422 Unprocessable Entity
Запрос корректно разобран, но содержание запроса не прошло серверную валидацию.
Например, в теле запроса были указаны неизвестные серверу поля, или не были указаны обязательные, или с содержимым полей что-то не так.
Обычно это означает ошибку в введённых пользователем данных, но может также быть вызвано ошибкой на клиенте или несовпадением версий.
500 Internal Server Error
Возвращается, если на сервере вылетело необработанное исключение или произошла другая необработанная ошибка времени исполнения.
Всё, что может сделать клиент в этом случае — это уведомить пользователя и сделать console.error(err) для более продвинутых товарищей (админов, разработчиков и тестировщиков).
501 Not Implemented
Возвращается, если текущий метод неприменим (не реализован) к объекту запроса.
Ну вот, в общем-то, и всё. Спасибо за внимание!