Кто правильно ищет - тот всегда находит
html5
vpvlab
Сайт http://trade.mikoyan.ru поможет быстро найти место с самой вкусной колбасой России. :))
Торговая география Микояновского мясокомбината позволяет приобрести его продукцию в 1000 разных мест по всей Москве.
Вы сможете выбрать ближайший к вам магазин по округу города Москвы или ближайшей станции метро.



[еще картинки]
Управляемые бины Managed Beans
html5
vpvlab

Управляемые бины Managed Beans

Центральной проблемой в дизайне web-приложений является разделение уровня представления и уровня бизнес-логики. В технологии JSF такое разделение достигается с помощью бинов (beans). JSF-страницы ссылаются на свойства бинов, а логика программы закладывается в код реализации этих бинов. Поскольку бины играют такую фундаментальную роль в JSF-программировании, есть смысл рассмотреть их более подробно, чтобы не путать с Enterprise JavaBeans.

Согласно спецификации JavaBeans (которая доступна по адресуhttp://java.sun.com/products/javabeans), бин Java — это допускающий многократное использование программный компонент, которым можно манипулировать в инструментах-конструкторах. Данное определение является слишком общим и в действительности бины используются для многих других целей.

На первый взгляд может показаться, что бин аналогичен объекту. Но бины имеют другое значение. Создание и манипулирование объектами осуществляется в Java-программе, когда она запускает конструкторы и вызывает методы.  С другой стороны, бины могут создаваться и подвергаться различному манипулированию без программирования.

Обратите внимание! “Bean”(бин) дословно переводится как «боб». Все дело в том, что слово “Java” в США ассоциируется не только с островом Ява, но и с популярной маркой кофе, а кофе, как известно, готовиться из кофе-бобов, которые и формируют его вкус. Кого-то эта аналогия забавляет, кото-то раздражает, но главное, что термин «бин» уже довольно прочно закрепился и вряд ли будет заменен каким-либо другим.

[Spoiler (click to open)]

Классическим приложением для JavaBeans является конструктор пользовательских интерфейсов. В окне палитры этого конструктора содержатся бины компонентов, такие как текстовые поля, ползунки, флажки и т.д. вместо написания кода Java разработчик с помощью конструктора пользовательских интерфейсов перетаскивает нужные бины из палитры в форму, а затем настраивает бины путем выбора свойств значений в диалоговом окне страницы свойств.

В технологии JSF бины применяются для сохранения состояния web-страниц. Создание бинов и манипулирование ими осуществляются под управлением реализации JSF, которая выполняет следующее:


  1. Создание и уничтожение бинов по мере необходимости (этим объясняется происхождение термина «управляемые бины»)

  2. Считывание свойств бина при отображении web-страницы

  3. Задание свойств бина при отправке формы

Рассмотрим в качестве примера поле формы для ввода пароля:

<h:inputSecret value=”#{user.password}” />

Реализация JSF должна определить местонахождение класса бина для бина с именем user. В этом примере класс UserBean объявлен следующим образом:

@ManagedBean(name=”user”)
@SessionScoped
public class UserBeans implements Serializable { … }

Атрибут name в аннотации @ManagedBean можно опустить. В таком случае имя бина формируется из имени класса путем приведения первой буквы к нижнему регистру. В частности, если в приведенном выше примере будет исключено выражение (name=”user”), то бин получит имя userBean.

Обратите внимание! Аннотация @ManagedBean находится в пакете javax.faces.bean. платформа Java 6 EE определяет в пакете javax.annotation другую аннотацию @ManagedBean, которая не работает с JSF.

Впервые встретив выражение с именем user, реализация JSFсоздает объект класса UserBean. Этот объект продолжает существовать на протяжении всего сеанса: это означает, что все запросы, исходящие от одного и того же клиента, продолжают оставаться действительными до явного завершения сеанса или его прекращения по тайм-ауту. На протяжении всего сеанса имя бина user ссылается на ранее созданный объект.

В любой конкретный момент времени на сервере могут быть активными сеансы, которые принадлежат разным клиентам. В каждом из этих сеансов применяется свой собственный объект UserBean.

Обратите внимание! Класс UserBean реализует интерфейс Serializable. Это требование для управляемого бина JSF не является обязательным, но его соблюдение настоятельно рекомендуется для бинов, действие которых охватывает весь сеанс. Серверы приложений могут обеспечивать лучшее управление для сериализуемых бинов, например, поддерживать кластеризацию.

Вполне очевидно, что JSF-разработчику не приходится писать код Java для создания бина user и манипулирования им. Реализация JSF создает бины и обращается к ним в соответствии с тем, как описано выражениями на страницах JSF.

Tags: ,
Аутентификация на основе jdbcRealm в GlassFish 3
html5
vpvlab
доступ на основе jdbcRealm в GlassFish 3

Разграничение прав доступа к разным частям сайта — один из самых важных этапов в разработке. Управление доступом должно быть гибким и надежным, чтобы в любой момент можно было быстро и без риска изменить правила пользования ресурсом. Все это может обеспечить аутентификация на основе jdbcRealm, который содержит в себе гибкость и настраиваемость базы данных и надежность использования от сервера приложений GlassFish.

jdbcRealm однозначно удобнее, продвинутее, управляемее и переносимее в сравнении со стандартными методами аутентификации: BASIC(базовая аутентификация), DIGEST(аутентификация на основе дайджеста), FORM(аутентификация на основе форм)и CLIENT-CERT(аутентификация на основе клиентского сертификата).jdbcRealm = гибкость базы * надежность сервера.

Давайте сформулируем задачу и требования, которые мы хотим реализовать.

Задача: создать гибкую в настройке возможность аутентификации разных групп пользователей на основе использования базы данных и возможностей сервера приложений GlassFish.

Требования: нам нужны три группы пользователей — администратор(admin), модератор(moder) и гость(guest). В любую из этих групп может входить неограниченное количество пользователей. Администратору доступны все уровни, модераторам — свой и гостевой, гостям — только свой. Шифрование паролей в базе данных — на основе MD5(чтобы можно было осуществлять шифрование на основе sql-запроса не заморачиваясь на java-код). Все страницы требующие прав доступа — только в защищенной зоне HTTPS. База дынных: MySQL, MyISAM.

Итак, поехали.

Области действия бинов Bean Scopes
html5
vpvlab

Для удобства программиста web-приложений контейнер JSF предоставляет отдельные области действия, каждая из которых управляет отдельной таблицей привязок «ключ – значение». В этих областях действия обычно хранятся бины и другие объекты, которые должны быть доступны в различных компонентах web-приложения.

При определении бина необходимо определить его область действия. Три области действия являются общими для управляемых бинов JSF и CDI.


  • Область действия сеанса:  SessionScoped

  • Область действия запроса:  RequestScoped

  • Область действия приложения:  ApplicationScoped

В версии JSF 2.0 дополнительно предусмотрены область действия просмотра ViewScoped и пользовательские области действия CustomScoped. Эти области действия не поддерживаются в технологии CDI — вместо этого в ней предусмотрена намного более полезная область действия диалога  ConversationScoped.

Обратите внимание! Аннотации для управляемых бинов JSF находятся в пакете javax.faces.bean, а аннотации для бинов CDI — в пакете javax.enterprise.context.

Область действия сеанса — SessionScoped

Уточним, что HTTP-протокол не поддерживает состояния. Браузер отправляет запрос серверу, сервер возвращает ответ, а затем ни браузер, ни сервер не берет на себя никаких обязательств хранить в памяти какие-либо сведения об этой транзакции. Такая простая организация работы вполне подходит для извлечения однозначно определяемых сведений, но не применима для серверных приложений.

[Spoiler (click to open)]

Поэтому контейнеры сервлетов дополняют HTTP-протокол средствами отслеживания сеансов, под которыми подразумеваются повторные подключения одного и того же клиента. Самый простой способ отслеживания сеансов заключается в применении cookie-файлов, то есть пар «ключ-значение», которые сервер отправляет клиенту, чтобы получать их обратно при следующих запросах.

Если на клиенте не запрещены cookie-файлы, то сервер при каждом последюущем запросе получает идентификатор сеанса.

Процесс отслеживания сеансов с помощью cookie-файлов полностью прозрачен для web-разработчика, а если клиент не принимает cookie-файлы, то стандартные теги JSF обеспечивают перезапись URL-адресов автоматически.

Область действия сеанса сохраняется со времени установки сеанса и до времени его завершения. Сеанс завершается после того, как web-приложение вызывает метод invalidate применительно к объекту HttpSession или по истечению тайм-аута сеанса.

Область действия запроса — RequestScoped

Область действия запроса существует очень недолго, а точнее со времени отправки HTTP-запроса и до момента отправки ответа обратно клиенту. Если управляемый бин находится в области действия запроса, то его новый экземпляр создается при каждом запросе. Возможностью применения области действия запроса следует пользоваться, если задача стоит в уменьшении затрат на выделение памяти для области действия сеанса.

Кроме того, область действия запроса становится очень удобной для организации работы, если все данные бина хранятся на одной странице.

В область действия запроса часто помещают данные, относящиеся в сообщениям об ошибках и состоянии. Эти данные вычисляются при отправке клиенту данных формы и отображаются при подготовке ответа к выводу на экран. Аналогично с этим, тег f:loadBundle помещает в область действия запроса переменную связки, которая необходима только на этапе подготовки ответа к отображению в том же запросе.

При работе со сложными данными, такими как содержание таблицы, область действия запроса может оказаться неприемлемой, поскольку при работе с ней приходится вновь формировать данные после каждого запроса.

Обратите внимание! Только бины, находящиеся в области действия запроса, являются однопотоковыми, поэтому, по самой своей сути, потокобезопасными. Это может показаться удивительным, но бины, находящиеся в области действия сеанса, однопотоковыми не являются. Например, ничто не мешает пользователю отправлять ответы одновременно из нескольких окон браузера. Каждый из ответов будет обрабатываться отдельным потоком запроса. Если необходимо обеспечить потокобезопасноть, используя бины с областью действия сеанса, то невозможно обойтись без механизмов блокировки.

Область действия приложения — ApplicationScoped

Область действия приложения сохраняется на протяжении всего времени функционирования web-приложения. Эта область действия используется одновременно всеми запросами и всеми сеансами. Управляемые бины помещаются в область действия приложения, если каждый отдельный бин должен использоваться совместно во всех экземплярах web-приложения. В таком случае бин создается после первого запроса со стороны любого пользователя приложения и продолжает существовать до закрытия web_приложения на сервере приложения.

Но если бин с областью действия приложения отмечен как eager, то его экземпляр должен быть создан до отображения даже первой страницы приложения. Для этого используется следующая аннотация:

@ManagedBean(eager=true)

Атрибут eager впервые был введен в действие в версии JSF 2.0

Область действия диалога — ConversationScoped

Область  действия диалога распространяется на набор взаимосвязанных страниц. Она позволяет обеспечить сохранение определенных данных до достижения какой-то конкретной цели, не вынуждая хранить эти данные на протяжении всего пользовательского сеанса. Диалог закрепляется за конкретной страницей браузера или вкладкой.  В каждом отдельном сеансе может проходить несколько диалогов на разных страницах. Обеспечение такой возможности является важным требованием сточки зрения практики. Пользователи часто открывают еще одну вкладку, чтобы можно было просматривать разные части конкретного приложения параллельно.

Область действия диалога использовать несложно.  Для этого достаточно придерживаться ряда простых правил:


  • Использовать бин CDI, поскольку область действия диалога — это средство CDI, а не JSF

  • Использовать аннотацию @ConversationScoped

  • Добавить следующую переменную экземпляра:
    private @Inject Conversation conversation;
    эта переменная экземпляра будет автоматически инициализирована вместе с объектом Conversation при создании бина

  • Вызывать метод conversation.begin(), чтобы перевести бин в более широкую область действия — из области действия запроса в область действия диалога

  • Вызывать метод conversation.end(), чтобы удалить бин из области действия диалога

Образец использования бина с областью действия диалога:

package ru.model;
import javax.inject.Named;
import javax.enterprise.context.ConversationScoped;
import java.io.Serializable;
import javax.enterprise.context.Conversation;
import javax.inject.Inject;
@Named(value = "dialogBean")
@ConversationScoped
public class DialogBean implements Serializable {
   @Inject Conversation conversation;
   private int currentIndex;
   public void setAnswer(String newValue) {
       try {
           if(currentIndex == 0) this.conversation.begin();
           // a lot of your code here
           if(currentIndex == 0) this.conversation.begin();
       } catch(NumberFormatException e){}
   }
   public DialogBean() {
   }
}

Область действия просмотра — ViewScoped

Область действия просмотра была впервые введена в версии JSF 2.0. Бин в области действия просмотра сохраняется до тех пор, пока отображается одна и та же страница JSF. После того как пользователь откроет другую страницу, бин выходит из области действия просмотра.

Если в состав приложения входит страница, которая постоянно остается открытой, то можно поместить бины, хранящие данные для этой страницы, в область действия просмотра, что будет способствовать уменьшению затрат памяти для области действия сеанса. Это особенно важно для приложений на основе AJAX.

Пользовательские области действия — CustomScoped

В конечном счете область действия — это просто карта, которая связывает имена с объектами. Основным признаком, по которому область действия одного типа отличается от другого, является срок существования соответствующей карты. Сроками существования четырех стандартных областей действия JSF:


  1. Сеанс  :  SessionScoped

  2. Приложение  :  ApplicationScoped

  3. Просмотр  :  ViewScoped

  4. Запрос  :  RequestScoped

управляет реализация JSF. А с выходом версии JSF 2.0 появилась возможность создавать пользовательские области действия — карты, сроками существования которых можно управлять самостоятельно. Бин помещается в такую карту с помощью следующей аннотации:

@CustomScoped(“#{expr}”)

Здесь используется выражение #{expr}, вычисление которого приводит к получению карты для области действия. При этом ответственность за удаление объектов из карты возлагается на приложение.

Tags: ,
Работа с правками файлов в GitHub и NetBeans
html5
vpvlab

В предыдущей статье мы залили часть файлов своего проекта на GitHub. Причем сделали это непосредственно из NetBeans — безо всяких приблуд = принцип одного окна, так сказать :)

Теперь же пришел черед узнать — как обмениваться правками вносимыми в файлы: как локально, так и на GitHub-е. То есть: можно изменить файл непосредственно на сервисе GitHub — для этого там есть редактор —  а затем применить эти правки к локальному файлу , а можно исправить файл на локальном компьютере — а затем залить на GitHub.

Особо стоит отметить, что создание/удаление директорий также может быть применено в оде стороны. Только запомните: пустые директории не создаются и не заливаются на GitHub! В нужной, но еще не заполненной директории должен быть хотя бы один файлик с минимальным содержанием...

Итак, поехали...

[Spoiler (click to open)]

Сценарий первый: правка файла непосредственно на GitHub с помощью их встроенного on-line редактора файлов.


  • переходим на нужную ветку, в нужную директорию и к нужному файлу

  • нажимаем кнопочку Edit справа и редактируем наш файл как считаем нужным

  • заполняем поля Commit summary и Extended description, нажимаем кнопку CommitChanges

  • открываем NetBeans

  • клик правой клавишей по проекту и выбор в меню: Git — ветвь — переключиться на ветвь - на локальном компе у вас должна быть ветка с таким же названием и содержимым как на GitHub

  • клик правой клавишей по проекту и выбор в меню: Git —удаленный — вытянуть = в появившемся окне указываем удобноевам удаленное имя репозитория, URL к нему, логи и пароль, жмем кнопку Далее и на новой вкладке выбираем ту ветку, которую мы правили в редакторе на GitHub (ее придется запомнить), жмем кнопку готово - IDE зальет файлы с сервиса и заменит ими файлы на локальном компьютере

  • все! мы применили к локальным файлам изменения сделанные на GitHub

Сценарий второй: правка файла на локальном компьютере.


  • открываем NetBeans

  • клик правой клавишей по проекту и выбор в меню: Git — ветвь — переключиться на ветвь и выбираем ту ветвь с которой хотим работать - на локальном компе у вас должна быть ветка с таким же названием и содержимым как на GitHub

  • редактируем нужный нам файл так как хотим

  • клик правой клавишей по проекту и выбор в меню: Git — фиксировать и в верхнее поле вписываем комментарий по поводу своих изменений

  • кликаем правой клавишей по проекту и в контекстном меню выбираем: Git — удаленный — вытолкнуть и далее как описано тут в пункте №9 - если в окне, где выбирается ветка на удаленном репозитории напротив нужной ветки будет красная буква — значит есть не принятые вами изменения и пока вы их не примете или не отклоните залить новые свое на GitHub будет невозможно

  • если возник конфликт, то клик правой клавишей по проекту и выбор в меню: Git —разрешить конфликт = после его разрешения можно будет залить свои изменения на GitHub

  • все! мы применили к файлам на GitHub изменения сделанные на локальном компьютере

?

Log in