Процедуры и функции в модулях управляемых форм, а также в общих клиентских модулях управляемого приложения, требуют четкого определения среды выполнения программного кода.
Клиент и сервер без контекста»); КонецПроцедуры Клиент и сервер»); КонецПроцедуры
Для этих целей, в общей сложности, используются пять директив препроцессора: НаСервере, НаКлиентеНаСервереБезКонтекста, НаСервереНаКлиенте
Данная директива может применяться только в модуле команды. Сама процедура или функция, объявленная с такой директивой, может быть использована как на клиентской, так и на серверной стороне в модуле команды. Приведу пример использования в команде справочника. Для этого в тестовой конфигурации добавим команду «Тестируем» для справовочника «ПростойСправочник»:
Модуль команды содержит следующий программный код:
ТестСерверКлиент(); КонецПроцедуры// Процедура для тест. вызова процедуры с СЕРВЕРА Сервер»); ТестСерверКлиент(); КонецПроцедуры// Процедура для тест. вызова процедуры с КЛИЕНТА Клиент и сервер»); КонецПроцедуры
Теперь рассмотрим поведение платформы при ее выполнении. Вызовем команду в режиме предприятия и проанализируем количество вызовов сервера. Картина будет следующей:
Что такое Windows Server и в чем отличие от Windows?
Таким образом, при вызове процедуры с директивой препроцессора «НаКлиентеНаСервере» с клиентской стороны вызова сервера не происходит. Единственный вызов сервера в нашем прмере происходил при обращении к серверной процедуре «Сервер».
Из всего вышесказанного можно заключить, что процедуры и функции с директивой » НаКлиентеНаСервере» фактически имеет те же возможности, что и клиентские процедуры и функции с директивой «НаКлиенте». Использование директивы «НаКлиентеНаСервере» позволяет вызывать любые процедуры модуля команды, а также получать доступ к клиентскому контексту формы.
На мой взгляд, использование подобных процедур и функций усложняет читабельность программного кода. Если использовать директивы «НаКлиенте», «НаСервере» и «НаСервереБезКонтекста», то код будет более понятным и предсказуемым.
Рассмотрим теперь работу процедур и функций с директивой «.
НаКлиентеНаСервереБезКонтекста» может быть использована в модулях управляемых форм на клиенте и на сервере. При этом такие процедуры и функции не могут получить доступ к контексту формы, всем экспортным переменным формы, но возможен вызов процедур и функций из серверных общих модулей, а тажке не глобальных серверных и клиенских одновременно.
Рассмотрим небольшой пример их использования. В модуле формы элемента справочника «ПростойСправочник» напишем следующий программный код:
КонецПроцедуры На клиенте и на сервере без контекста»); КонецПроцедуры
Процедура «Тестируем» принадлежит команде формы. При ее запуске осуществляется вызов процедуры «ТестируемКлиентСервер» с директивой «НаКлиентеНаСервереБезКонтекста». Как было сказано выше, данная процедура не сможет получить доступ к контексту формы и другим клиентским процедурам. Но все серверные процедуры модуля формы без контекста будут доступны для вызова, а также серверные процедуры общего модуля.
Уроки администрирования / Что такое сервер простыми словами для начинающих
Вызов сервера будет произведен, что логично, при вызове серверной процедуры со стороны клиента.
Вывод
Подытожим выше сказанное:
- Процедуры и функции с директивой «НаКлиентеНаСервере» используются только в модулях команд и ограничены возможностями клиентской стороны.
- Процедуры и функции с директивой «НаКлиентеНаСервереБезКонтекста» используются только в модулях форм и позволяют работать с серверной стороной без передачи контекста формы (реквизиты формы, экспортные переменные модуля формы и др.).
- Основное различие между двумя рассматриваемыми директивами — это контекст их применения. Одна команда препроцессору используется только в модулях команд, другая в модулях управляемых форм.
За весь опыт работы с управляемыми формами использовать подобные процедуры и функции приходилось очень редко. Как уже говорил выше, считаю, что их исопльзование ухудшает читабельность кода.
Источник: 1clancer.ru
Экскурс в REST API и знакомство с Postman
как инструментом для вызова REST API-методов
Тестирование REST API является важной частью процесса разработки программного продукта. В этой статье мы поговорим о программной архитектуре, рассмотрим что такое API вообще и REST API в частности, познакомимся с Postman — инструментом для тестирования и документирования API-методов.
Что такое REST?
- Client-Server. Система должна быть разделена на клиентов и серверов.
- Stateless. Сервер не должен хранить какой-либо информации о клиентах. В запросе должна храниться вся необходимая информация для обработки запроса и, если необходимо, идентификации клиента.
- Cache․ Клиенты и промежуточные узлы могут кешировать ответы сервера.
- Uniform Interface. Единый интерфейс определяет взаимодействие между клиентами и серверами.
- Layered System. Допускается разделить систему на иерархию слоев, но с условием, что каждый компонент может видеть компоненты только непосредственно следующего слоя.
- Code-On-Demand (опционально). Возможно выполнение кода на стороне клиента.
Таким образом, REST — способ организации программной системы, построенный на вышеуказанных принципах. Приложения, которые полностью придерживаются этих принципов, называются RESTful. Для приложений, которые частично учитывают принципы REST, используют термин REST-like.
Преимущества приложения,
разработанного на основании REST
Рой Филдинг в своей диссертации писал, что применение указанных выше ограничений способствует созданию приложения, которое будет обладать важными преимуществами:
- Надёжность. Обеспечивается за счёт отсутствия необходимости сохранять информацию о состоянии клиента, которая может быть утеряна.
- Производительность. Достигается за счёт использования кеша.
- Масштабируемость. Важна для обеспечения большого числа компонентов в системе и взаимодействий между ними.
- Прозрачность взаимодействия между системами по сети.
- Простота интерфейсов.
- Портативность компонентов. Другими словами, переносимость компонентов системы путем перемещения программного кода вместе с данными.
- Легкость внесения изменений. Можно легко вносить изменения в существующий компонент системы, если он слабо связан с другими компонентами.
- Способность эволюционировать, приспосабливаясь к новым требованиям.
Воркшоп «Проектирование интеграции с REST API»
- познакомиться с REST API,
- спроектировать интеграцию «с нуля»,
- систематизировать знания и навыки в REST-интеграциях.
Трёхуровневая архитектура
Трёхуровневая архитектура предполагает, что инициатором запроса является так называемый «клиент», то есть клиентское приложение. Уровни архитектуры мы далее будем называть «слои» — это общепринятый в ИТ-среде термин.
- Слой клиента (интерфейс пользователя) — необходим для того, чтобы разные клиенты могли единообразно обращаться к бизнес-логике, реализованной на сервере.
- Слой логики (сервер) — обеспечивает выполнение бизнес-логики.
- Слой данных (база данных) — обеспечивает хранение данных. Сервер получает данные и использует их для осуществления бизнес-логики.
Трёхуровневая архитектура
Application programming interface (API)
Каждый слой архитектуры взаимодействует только с соседним слоем, то есть интерфейс пользователя не обращается к базе данных напрямую — только через сервер приложений.
Поговорим теперь подробнее о том, как получить все преимущества приложения, разработанного на основании REST.
Для этого рассмотрим следующую схему:
Способы взаимодействия компьютерных программ
Справа на схеме мы видим базу данных, с которой взаимодействует бизнес-логика.
Слева — различные клиенты, которые хотят добраться до бизнес-логики, реализованной на сервере. Как сделать так, чтобы обращение к бизнес-логике было единообразным для всех клиентов? Для решения данной задачи и существует программный интерфейс (на схеме это REST API).
Таким образом, API (Application programming interface) — это описание способов, с помощью которых одна компьютерная программа может взаимодействовать с другой.
- Операцию, которую мы можем выполнить;
- Данные, которые поступают на вход;
- Данные на выходе (данные или сообщение об ошибке).
Вызов операций REST API
Клиентские приложения обращаются к REST API по протоколу HTTP. Другими словами это называется отправляют «HTTP-request». В рамках данной статьи мы будем обращаться к REST API стороннего приложения с помощью программы Postman. Прежде, чем мы приступим непосредственно к практической части статьи, давайте проговорим термины, необходимые для понимания сути происходящего.
HTTP — широко распространённый протокол передачи данных, изначально предназначенный для передачи документов. Когда мы говорим «протокол», то имеем ввиду четко специфицированные правила передачи информации, которые клиент и сервер должны соблюдать и выполнять.
Давайте рассмотрим структуру HTTP-запроса, поскольку для обращения к стороннему приложению мы должны сделать как раз это — отправить http-request. Любой HTTP-запрос состоит из трёх частей:
- Стартовая строка
Приведу несколько примеров:
Источник: systems.education
Самые основы. Как работает PHP.
Отличие веб-приложения от обычной программы
Начиная писать программы для веба, многие начинающие программисты сталкиваются с такой ошибкой. Они рассматривают систему браузер-сервер, как обычное приложение. Интерактивное. Нажал кнопку — система среагировала. Провел мышкой — среагировала.
Вся информация, которая доступна клиенту — доступна и программе, программа все время находится в памяти.
Так вот, в веб-программировании это не так!.
В момент, когда пользователь видит перед собой страницу и начинает совершать какие-то действия с ней, PHP уже завершил работу! И пользователь взаимодействует не с PHP скриптом, а со своей страницей HTML, которую он получил в браузер. Результатом работы скрипта на PHP в большинстве случаев является обычный текст. Текст HTML страницы. Которая отдается браузеру и показывается им, как обычный HTML. Вы сами можете в этом убедиться, написав в скрипте
Вася!»; ?>;
А потом просмотрев в браузере исходный текст полученной страницы. Никаких тегов PHP там нет! Только
Привет, Вася!
Потому, что PHP исполняется на сервере!
Сервер и браузер общаются, посылая друг другу запросы по особому протоколу — HTTP. Соединение может инициировать только браузер. Он посылает серверу запрос — показать такой-то файл. Сервер клиенту файл посылает.
Только так и происходит. Клиент запросил — сервер отдал. И забыл сразу о клиенте. Отсюда становится понятным ответ на вопрос, можно ли точно узнать, сколько юзеров сечас на сайте. Нельзя. потому, что «на сайте» нету ни одного.
Они соединяются, запрашивают страницу, и отсоединяются. Не имеют постоянного cоединения с сервером, как, например, игроки в Кваку. Узнать можно только примерно, записывая время каждого соединения и выбирая записи за определенный промежуток времени.
Так же, отсюда становится ясно, что сервер может узнать о клиенте очень мало. Только то, что клиент пришлет в HTTP-запросе. Разрешения экрана там нет 😉
Все, что сервер может знать о клиенте, можно посмотреть командой phpinfo()
Пример общения браузера с сервером:
Пользователь нажимает на ссылку, браузер посылает запрос серверу и ждет ответа:
Браузер -> PHP
PHP выполняет скрипт, отдает результат в браузер и завершает работу:
PHP -> браузер
Браузер отображает страницу, «просматривая» её на предмет ссылок, которые надо запросить у сервера (теги , и так далее) и посылает соответствующие запросы. Их можно увидеть, просматривая обмен заголовками, о чем речь будет чуть ниже:
Браузер -> сервер, Браузер -> сервер, Браузер -> сервер.
Пользователь заполняет форму и нажимает на кнопку:
Браузер -> PHP
PHP обрабатывает форму, записывает данные в базу и посылает браузеру заголовок
Location:
PHP -> браузер
Браузер, получив этот заголовок, запрашивает указанную страницу
Браузер -> PHP
PHP выполняет ее. и так далее.
Как работает РНР, где он выполняется?
РНР выполняется на сервере. Браузер посылает серверу запрос на страницу с php кодом. Сервер отдает эту страницу на исполнение интерпретатору PHP, интерпретатор генерирует HTML код, отдает серверу, а сервер посылает клиенту. Никакого РНР кода в браузер не попадает (это важно! Это значит, что увидеть исходный код PHP скрипта невозможно!).
Единственный способ отправить что-то скрипту — это кликнуть по ссылке или нажать на кнопку в форме. Так, чтобы РНР обрабатывал какие-то действия пользователя в браузере — невозможно. РНР остался на сервере, ждать новых запросов с данными для обработки. PHP, но не скрипт! Скрипт, который выполнялся, отдавая пользователю страницу, завершил работу.
Все данные, которые были в нем — пропали. Именно поэтому, если какая-то переменная нужна при последующих вызовах скрипта, ее надо этому скрипту передать снова.
Очень качественная и подробная статья об основах веб-программирования находится на сайте PHPWIKI.RU. Обязательно прочитайте её.
Как передать переменную из PHP в JavaScript и обратно?
Начнем с того, что никакую переменную передать, конечно же, невозможно. Поскольку переменная — это часть программы. И из одной в другую передать её нельзя. Передать можно только значение переменной. Т.е. текст.
То есть, различия между «передачей переменной в яваскрипт» и формированием html таблицы НЕТ НИКАКОГО!
Отсюда вывод — «Передать переменную» в Javascript очень легко. Особенно, повторюсь, если учесть, что никакой «передачи» не происходит. PHP просто напросто генерирует яваскрипт точно так же, как и всю остальную страницу, вместе со всеми переменными.
Точно так же, как вы выводите в браузер строку «Hello World, это Вася Пупкин!», выводится и любой яваскрипт, со всеми своими переменными.
Единственное условие — вы должны представлять себе тот яваскрипт, который хотите получить.
К примеру в PHP есть переменная $name=»Вася» , значение которой надо передать в яваскрипт, чтобы получить
name=»Вася»;
Мы просто пишем
$name=»Вася»;
?>
name=»»
То есть, фактически, мы просто сформировали нашим PHP скриптом некий текст, который выглядит, как нужный нам код на яваскрипте. Или, с другой стороны, мы писали свой яваскрипт, в нужных местах вставляя вывод переменных из PHP.
Чтобы не сойти с ума от разнообразных кавычек, настоятельно рекомендуется яваскрипт выводить не весь с помощью echo, а именно так, как написано здесь — закрыв тег PHP и открывая их только там, где нужно вывести переменную.
Как передать переменную из яваскрипта в PHP?
Точно так же, как и любые другие данные — послав запрос на сервер.
Но надо четко понимать, что во время выполнения php скрипта получить что-либо из яваскрипта, разумеется, невозможно. Передать можно будет только при следующем запросе. И обрабатывать его будет уже другой PHP скрипт.
Если надо по событию onClick обратиться к базе данных, то следует помнить, что она находится на сервере. То есть, надо запрашивать сервер, который запустит PHP скрипт, который обратится к базе, получит от неё ответ и передаст его в браузер.
Все вышеизложенное не противоречит, разумеется, модной технологии асинхронного общения браузера с сервером. Все методы остались те же, просто общение с сервером выполняет не сам браузер, а программа на яваскрипте.
Подробнее можно почитать на ресурсах, посвященных яваскрипту. С точки зрения PHP запросы по технологии AJAX ничем не отличаются от обычных.
Способы общения браузера с сервером.
Способов, предоставляемых протоколом HTTP, немного. Это важная информация. Никаких других способов нет. На практике используются два:
GET — это когда данные передаются в адресной строке, например, когда пользователь жмет ссылку.
POST — когда он нажимает кнопку в форме.
Сформировали страницу со ссылкой или с формой методом GET — запрос придет GET-ом. Сформировали с формой, в которой указан метод POST — придет POST-ом.
Определить, какой способ следует применять, очень просто. Если форма служит для запроса некой информации, например — при поиске, то ее следует отправлять методом GET. Чтобы можно было обновлять страницу, можно было поставить закладку и или послать ссылку другу.
Если же в результате отправки формы данные записываются или изменяются на сервере, то следует их отправлять методом POST, причем обязательно после обработки формы надо перенаправить браузер методом GET. Так же, POST может понадобиться, если на сервер надо передать большой объём данных (у GET он сильно ограничен), а так же, если не следует «светить» передаваемые данные в адресной строке (при вводе логина и пароля, например). Но в любом случае, после обработки POST надо всегда перенаправлять браузер на какую-нибудь страницу, пусть ту же самую, но уже без данных формы, чтобы при обновлении страницы они не записывались повторно. Например:
header(«Location: http://».$_SERVER[‘HTTP_HOST’].$_SERVER[‘REQUEST_URI’]);
exit;
Самое главное, что надо помнить: сервер по своей инициативе обратиться к клиенту не может. Мы можем только по факту запроса выдать что-то браузеру — либо страницу, либо команду запросить другой ресурс.
Полезная информация может содержаться в различных НТТР заголовках.
Cookie — если сервер поставил куку, и она не устарела, то браузер отсылает ее вместе с каждым запросом.
HTTP authentication — если сервер запрашивал HTTP авторизацию, то браузер при каждом обращении шлет введенные логин и пароль.
РНР может посылать HTTP заголовки двумя командами — header() и setcookie() .
Просмотр обмена HTTP заголовками
Я очень рекомендую попрактиковаться с HTTP заголовками, посмотреть, как ими обмениваются сервер и клиент.
Для этого есть множество разных способов. Если у вас стоит популярный download manager FlashGet, то можно использовать его. Так же заголовки показывает популярная программа Proxomitron, можно скачать какие-нибудь специальные утилиты.
Для IE можно предложить плагин http://blunck.se/iehttpheaders/iehttpheaders.html
Для браузера Mozilla есть удобный плагин http://livehttpheaders.mozdev.org/
Так же, существует много других утилит, легко находимых в сети по запросу HTTP sniffer.
Обязательно воспользуйтесь любым способом посмотреть HTTP заголовки, которыми обменивается браузер с сервером. Это очень хорошая практика, а так же проверка — что шлет твой скрипт. Удобно при отладке установки кук или проблемах с сессиями.
Примерное представление о пришедших заголовках можно также получить, воспользовавшись функцией getallheaders() . Но следует учитывать, что работает она только если PHP собран, как модуль.
ОЧЕНЬ ВАЖНОЕ ЗАМЕЧАНИЕ
Из того факта, что PHP исполняется на сервере, и посылает результат своей работы браузеру, следует один простой, но очень важный вывод. Что PHP в принципе НЕ МОЖЕТ отобразить в браузере ничего такого, что невозможно было бы сделать средствами html.
ПРЕЖДЕ, чем что-то писать на PHP — попробуйте это сделать чистым HTML.
«Нажатие на Энтер» не переводит строку? А в html вы не пробовали таким образом строки переводить? Не получилось? Какая досада. Прочитайте, как в html сделать перевод строки и приходите снова.
PHP в результате своей работы формирует не картинку с текстами, как вы ее видите на экране монитора! PHP формирует HTML код! И этот код ЗНАЧИТЕЛЬНО отличается от того изображения, которое вы видите на экране. Если у вас что-то не получается, то надо всегда смотреть именно ИСХОДНЫЙ код страницы, а не то, как вам ее рисует браузер. В браузере Internet Explorer исходный код можно посмотреть, выбрав в меню Вид — Просмотр HTML-кода.
Если у вас не работает яваскрипт, сформированный PHP скриптом, или html показывает не то, что вы хотите, то исправить эту проблему очень просто.
1. Сначала пишете нужный яваскрипт или html руками. Если у вас с этим проблемы — обратитесь в соотвествующий форум — по яваскрипту или html. PHP тут не при чём.
2. Сравниваете с тем, что получено из PHP
3. Вносите исправления в PHP скрипт, чтобы текст, отдаваемый им, не отличался от написанного руками.
Браузер не умеет показывать файлы, в которые напихан одновременно и html картинки. Браузер умеет показывать только известные ему типы данных. В частности, это ИЛИ html ИЛИ картинка. Но не вместе. Если картинка — то ОДНА.
Несколько картинок подряд браузер показывать не умеет. Браузер умеет показывать HTML, в котором прописаны ССЫЛКИ на несколько картинок.
Пожалуйста, прежде, чем изучать PHP — изучите хотя бы основы HTML! Прежде, чем что-то требовать от PHP — попробуйте сделать это на html.
Источник: phpfaq.ru