Используем сервис Gravatar

Название Gravatar переводится как "глобально распознаваемые аватары", и предназначен для хранения и глобального доступа к аватаркам пользователя и его персональным данным.

Все URL-ы в системе gravatar имеют одну общую ключевую деталь - хеш адрсеса электропочты пользователя. Именно этот хеш уникально идентифицирует пользователя в рамках сервиса gravatar. Хеш формируется очень просто. Для этого нужно взять e-mail, убедиться, что в нем отсутствуют начальные и конечные пробелы, привести его в нижний регистр, и взять MD5-хеш полученной строки.

На языке PHP этот код будет выглядеть так:

$email = "vgrinin@gmail.com";
echo md5(strtolower(trim($email)));

А на C# - вот так:

string email = "vgrinin@gmail.com";
byte[] hash = MD5.Create().ComputeHash(Encoding.Default.GetBytes(
  email.Trim().ToLower()));
StringBuilder hashString = new StringBuilder();
for (int i = 0; i < hash.Length; i++)
{
  hashString.Append(hash[i].ToString("X2"));
}
Console.WriteLine(hashString.ToString().ToLower());

Colored with dumpz.org

Гм... получилось несколько длиннее, чем на PHP.

Протестируйте работу алгоритма, введите свой e-mail в поле ввода ниже и нажмите кнопку "Преобразовать" здесь.

Ну что же, теперь все готово, чтобы, используя полученный хеш, запросить с сервера gravatar изображение аватарки или профиль пользователя. Начнем с аватарки.

В самом простейшем случае запросить аватарку можно при помощи URL-а: http://www.gravatar.com/avatar/HASH. Здесь HASH - это MD5-хеш, полученный из e-mail на предыдущем шаге. Ответом на этот запрос явится изображение, которое можно отобразить на странице при помощи тега IMG, таким образом: <img src="http://www.gravatar.com/avatar/HASH" />

Например, для меня (vgrinin@mail.ru) это будет выглядеть так:
<img src="http://www.gravatar.com/avatar/b902d209d0efede9d9113a03c4ccb756" />

По умолчанию, изображение идет в PNG-формате, но если вы хотите получить его например в JPG, то нет ничего проще - добавьте расширение в конце URL, вот так:
<img src="http://www.gravatar.com/avatar/b902d209d0efede9d9113a03c4ccb756.jpg" />

При помощи параметра s мы можем указать размер изображения в пикселях, от 1 до 512, вот так:
<img src="http://www.gravatar.com/avatar/b902d209d0efede9d9113a03c4ccb756.jpg?s=200" />

Размер задается только один, так как аватарки у gravatar`а - квадратные. Если сервис не находит картинки, то он отображает изображение по умолчанию. Если мы хотим задать какое-то конкретное изображение по умолчанию, то укажем его в параметре d, вот так:
<img src="http://www.gravatar.com/avatar/b902d209d0efede9d9113a03c4ccb756.jpg?s=200&d=http%3A%2F%2Fmyserver.ru%2Fimages%2Fdefault.jpg" />

Как видим, здесь просто задается полный URL до изображения, причем URL-encoded. Существует также ряд предопределенных значений параметра d, при этом изображение по умолчанию будет взято(сгенерировано) из одного из стандартных рядов изображений по умолчанию:

1. mm: человек-загадка, стандартное изображение человеческого силуэта (не изменяемое в зависимости от хеша)
2. identicon: абстрактная геометрическая фигура, сгенерированная в зависимости от хеша
3. monsterid: "уродцы", созданные из хеша, с разными лицами, цветов и т.д.
4. wavatar: лица-иконки, созданные из хеша, с разной формой, ыветом и т.д.
5. retro: 8-битные упрощенные лица-иконки

Попробуйте введите в поле формы здесь любую строку и посмотрите, какие варианты изображений по умолчанию создаст для вас сервис gravatar. А если ввести зарегистрированный в gravatar e-mail, то все 5 изображений будут одинаковыми и представлять собой не случайное изображение по умолчанию, а ваш собственный аватар.

Разберемся с еще одним URL-аргументом - r. Параметр r позволяет задать рейтинг отображаемого изображения. Что это значит? При регистрации в gravatar, пользователь может загрузить не одно, а несколько разных изображений. Каждое из них имеет свой, определяемый самим пользователем рейтинг:

• Граватары с ретингом G пригодны для показа на сайтах с любой аудиторией.
• Граватары с рейтингом PG могут содержать неприличные жесты, провокационно одетых людей, грубые выражения или умеренную жестокость.
• Граватары с рейтингом R могут быть оскорбительными, содержать сцены жестокости, обнаженные тела или связанные с наркотиками.
• Граватары с рейтингом X могут содержать откровенные сексуальные изображения или сцены экстремальной жестокости.

Честно сказать, я слегка недопонял этот параметр. Когда я в своем профиле на gravatar добавил еще несколько изображений с рейтингом PG, R и X, то получил в результате ситуацию, что на сайте отображается либо самый жестокий аватар, либо отображается картинка по умолчанию для сайтов с рейтингом жестокости пониже. То есть я ожидал, что в зависимости от параметра r, переданного в url я увижу на сайте соответствующее рейтингу изображение, но увидел лишь картинку по умолчанию, что мне кажется странным. Становится совершенно непонятным, зачем мне дана возможность загрузить несколько изображений, если в реальности работает только изображение с самым жестким рейтингом?

Если ваш сайт использует протокол HTTPS>, то вы можете использовать URL https://secure.gravatar.com/ для загрузки аватарок через SSL. Все остальные параметры остаются прежними.

Gravatar, помимо аватарок, может отдавать еще и информацию о профиле пользователя. В нее входят почтовые адреса, телефоны, номера ICQ, skype, адреса персональных сайтов, и адреса профилей в ряде социальных сетей, twitter-е и т.д. Конечно, если пользователь заполнил эту информацию на сайте gravatar.com.

Получить доступ к этой информации очень просто - достаточно обратиться к URL вида: http://www.gravatar.com/HASH, где HASH - все тот же самый md5-хеш адреса электропочты пользователя. Например, вот ссылка на мой профиль: http://www.gravatar.com/b902d209d0efede9d9113a03c4ccb756.

Попробуйте зайти по предложенному адресу и обратите внимание, что при обращении по этому адресу, ваш браузер получит редирект на url страницы профиля, например для моего профиля редирект будет вот на эту страницу http://ru.gravatar.com/vgrinin. Как видим, здесь просто добавился локализованный поддомен, и md5-хеш заменился на мой логин.

Обычно, сгенерированная страница профиля не годится для того, чтобы вставить информацию с нее в ваш сайт. Для этих целей создатели gravatar постарались и дали нам возможность получать информацию о профиле в нескольких удобных форматах: JSON, XML, PHP, VCF, QRCode.

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

А поэтому следует обратиться в сторону остальных форматов загрузки и, соответственно, серверной обработке данных. Если вы программируете на PHP то удобнее всего будет воспользоваться PHP-форматом данных, который представляет собой строку объекта, сериализованного методом serialize(), так что обратное преобразование в объект мы можем провести методом unserialize().

Чтобы не быть голословным, приведу пример PHP-кода, выводящего на экран ФИО пользователя и его аватарку.

$str = file_get_contents('http://www.gravatar.com/b902d209d0efede9d9113a03c4ccb756.php');
$profile = unserialize($str);
if (is_array($profile) && isset($profile['entry']))
{
 echo $profile['entry'][0]['name']['formatted'];
    echo '<br/><img src="'.$profile['entry'][0]['thumbnailUrl'].'"/>';
}

Colored with dumpz.org

Вот здесь вы можете протестировать этот скрипт. Обратите внимание, что желаемый формат информации профиля задается в виде "расширения" файла, запрашиваемого у сервиса. В нашем случае формат ".php".

Остальные форматы запрашиваем при помощи расширений: ".json", ".xml", ".vcf", ".qr". Саму структуру пакета данных удобнее всего просматривать в XML-формате, открыв в вашем браузере страницу http://www.gravatar.com/HASH.xml.

И еще хочу рассмотреть интересный формат - QRCode. Этот формат представляет собой 2D-штрих-код, в котором зашифрован URL вашего профиля. Расшифровать его можно, например, на этом сайте. Если ввести в поле ввода строку http://ru.gravatar.com/b902d209d0efede9d9113a03c4ccb756.qr (это мой QR-код), то получим вот такой результат:

Raw text http://gravatar.com/vgrinin
Raw bytes 41 b6 87 47 47 03 a2 f2 f6 77 26 17 66 17 46 17 22 e6 36 f6 d2 f7 66 77 26 96 e6 96 e0 ec 11 ec 11 ec 11 ec
Barcode format QR_CODE
Parsed Result Type URI
Parsed Result http://gravatar.com/vgrinin

Как видно, в Parsed Result здесь содержится только мой URL, а я надеялся увидеть там несколько более подробную информацию.

Вот мы и рассмотрели все тонкости работы с сервисом gravatar. Спасибо его создателям, ведь сервис получился действительно нужным и популярным. Следует добавить, что все популярные CMS в том или ином виде содержат API для работы с этим сервисом, так что зачастую не надо утруждать себя нахождение MD5-хешей и прочими трудностями.

Надеюсь, статья была интересной и полезной.

Сразу оговорюсь, какое отношение имеет цикл статей про Entity Framework к веб-программированию. В дальнейшем я собираюсь использовать полученную модель для создания веб-приложения на базе технологии ASP.NET MVC 3, которая очень хорошо сочетается с Entity Framework.

Прежде всего - вам нужно иметь установленную Visual Studio 2010 (кажется 2008 тоже подойдет) и установленный пакет ADO.NET Entity Framework 4.1 найдите его по ссылке или в поиске на microsoft.com. Теперь нам становятся доступны все возможности ADO.NET Entity Framework. Замечу, что четвертая версия отличается от более ранних, так что, если у вас установлена более ранняя версия, то не гарантирую, что у вас будет работать тот код, что я привел в статье.

Итак, создаем обычное консольное приложение. Присваиваем ему имя test1. Добавляем в проект модель данных. Add -> New Item... -> ADO.NET Entity Data Model, называем ее MyEFModel.edmx.

Среда разработки предлагает нам два варианта создания модели: генерация из базы данных и пустую модель. В этой статье мы собираемся рассмотреть принцип Model First, то есть начинать разработку мы будет с создания модели данных, из которой впоследствии будет сгенерирована схема данных (таблицы и связи в базе данных). А это значит, что мы выберем вариант создания пустой модели Empty Model. После этого перед нами откроется пустое поле дизайнера модели данных. Если дизайнер не открылся, то сделайте двойной клик на модели MyEFModel.edmx в Solution Explorer'е.

Итак, мы хотим спроектировать модель данных для проверки пользовательских прав на те или иные операции. А значит в модели данных у нас будут присутствовать следующие сущности: Пользователь (User), Группа (Group) и Право (Right). Каждый пользователь обязательно принадлежит какой либо группе, и при этом строго одной. Каждая группа содержит в себе несколько прав, или не содержит ни одного. Все просто - при регистрации нового пользователя создается одна сущность User, у которой есть свойство Group, привязывающее пользователя к конкретной группе пользователей(например, администраторы, модераторы, авторы, читатели, посетители). Группа в нашем случае это набор прав (таких как: "блокирует пользователя", "редактирует чужую статью", "создает статью", "читает статью" и т.д.).

Перед тем как создавать сущности, давайте скажем дизайнеру модели, по каким правилам будут формироваться имена коллекций сущностей. Я вот о чем. Одновременно с сущностью в модели создается также контейнер этих сущностей, то есть по сути коллекция. Аналогия с таблицей в БД прямая: сущность - это строка в таблице, контейнер сущностей - сама таблица. Дизайнер дает имя контейнеру исходя из имени сущности (имя контейнера, впрочем, всегда можно поменять), и для сущности User, контейнер он может назвать UserSet или Users. По мне так название Users гораздо приятнее. А потому для самой модели в свойствах мы выставим Pluralize New Objects = True.

Итак, создаем сущности(сущности создаются правым кликом на диаграмме модели данных и выбором контекстного меню Add -> Entity...):

1. Entity Name = User Entity; Set = Users. Остальные свойства оставим без изменений. Заметим лишь, что по умолчанию дизайнер модели создает первичный ключ Id целочисленного типа, что для нас вполне приемлемо. Добавляем в эту сущность свойства(Properties):
   • Login (Type = String, Max Length = 255);
   • Registered (Type = DateTime).
   
   Свойства добавляются в контекстном меню самой сущности (Add -> Scalar Property).
2. Entity Name = Group; Entity Set = Groups. Свойства: Name (Type = String, Max Length = 255).
3. Entity Name = Right Entity; Set = Rights. Свойства: Description (Type = String, Max Length = 255).

1. Association Name = UserGroup; Начало: Entity = User, Multiplicity = Many; Конец: Entity = Group, Multiplicity = One. Это соотношения "Один ко многим", то есть каждый пользователь может состоять только в одной группе, но в каждой группе может быть много пользователей. (Если бы у сущности Group мы выбрали Multiplicity = Zero or One, то мы бы получили отношение "Один ко многим", но дали бы при этом возможность иметь пользователей не принадлежащих ни одной группе, то есть у пользователя свойство Group было бы Nullable).
2. Association Name = GroupRight; Начало: Entity = Group, Multiplicity = Many; Конец: Entity = Right, Multiplicity = Many. Это соотношение "Многие ко многим", то есть группа содержит в себе множество прав, при этом каждое право может принадлежать нескольким различным группам.

Вот какая схема данных у нас появилась: рисунок


Обратите внимание, что после создания связей, в каждой из сущностей появились дополнительные навигационные свойства. Например, свойство Group сущности User дает нам возможность узнать группу, в которой состоит пользователь, а свойство Rights сущности Group дает нам возможность получить список всех прав группы. Таким образом, обратившись к concreteUser.Group.Rights мы получим список прав пользователя. Как видно из схемы данных, среда разработки создала также и встречные (обратные) навигационные свойства Right.Groups и Group.Users.

Ну что же, модель данных готова. Но чтобы начать писать программный код, оперирующий с данными, нужно для начала создать саму базу данных. Используя Visual Studio2010 сделать это очень легко.

Правый щелчок мыши на диаграмме, затем в контекстном меню "Generate Database from Model...". Здесь мы можем выбрать существующее подключение к БД или создать новое. Мы создадим новое подключение (кнопка New Connection...), здесь вы выбираете сервер БД, способ и параметры аутентификации, и имя базы данных (если хотите создать новую, то просто введите имя новой БД в поле Select or enter a database name), жмем OK. (Я создал базу EFUSERS на локальном компьютере). Мастер спросит вас нужно ли создать БД, вы соглашайтесь. После этого мы снова вернемся в мастер генерации БД, убедитесь, что галочка "Save entity connection settings in App.config as" установлена и нажмите Next. После этого во вкладке DDL мастер отобразит вам DDL-скрипт схемы данных. Здесь вы нажмите Finish.

После работы мастера мы получили следующее:

1. скрипт схемы данных в файле MyEFModel.edmx.sql,
2. строка подключения MyEFModelContainer в файле App.config (откройте его и посмотрите в раздел сonnectionStrings)
3. пока еще пустая база данных EFUSERS.

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

Теперь нам нужно выполнить DDL-крипт, чтобы создать все необходимые объекты в БД. Вы можете выполнить файл скрипта в Query Analizer, а можете сделать это прямо в Visual Studio, открыв скрипт и нажав кнопку Execute SQL в панели инструментов, или нажав комбинацию Ctrl+Shift+E. Студия запросит у вас параметры подключения к БД а затем выполнит скрипт. Открыв теперь базу в Enterprise Manager мы можем увидеть, что там создано 4 таблицы: Users, Rights, Groups, GroupRight. Первые три таблицы хранят в себе сущности трех видов, а вот четвертую Junction-таблицу (GroupRight) Entity Framework создал для того чтобы хранить отношения "Многие ко многим" между сущностями Group и Right. Как видим, при помощи подхода Model First мы полностью ушли от этапа проектирования таблиц в БД, всю работу Entity Framework сделал за нас. Обратим также внимание, что в таблице Users появилась колонка Group_Id ссылающаяся на группу, в которую входит пользователь, колонка эта NOT NULL, и это гарантирует что пользователь обязательно будет принадлежать той или иной группе. Ниже приведена схема БД, на которой отображены поля таблиц, первичные и внешние ключи.

Схема хранения данных: рисунок.


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

Я не буду приводить здесь DDL-скрипт, сгенерированный студией, но он доступен для ознакомления по ссылке MyEFModel.edmx

Ну вот, вся предварительная работа сделана, модель данных нарисована, схема данных создана, пустые таблицы в БД присутствуют. Осталось теперь попробовать поработать со всем этим добром.

Чтобы обратиться к данным в БД, нужно создать экземпляр контейнера модели. Класс контейнера называется MyEFModelContainer, инстанцируем его:

MyEFModelContainer cnt = 
  new MyEFModelContainer("name=MyEFModelContainer");

 В качестве аргумента конструктора мы задаем имя строки подключения к БД. Эта строка подключения представляет собой нечто большее, чем обычная ConnectionString для подключения к базе данных, потому что в нашем случае используется провайдер System.Data.EntityClient, которому для инициализации требуется гораздо больше параметров. Строка подключения была создана мастером ранее и хранится в файле App.config, строка подключения выглядит так:

provider=System.Data.SqlClient;
provider connection string="data source=.;initial catalog=EFUSERS;
integrated security=True;multipleactiveresultsets=True;App=EntityFramework"

Посмотрите внимательно, строка подключения имеет в себе три обязательных параметра: metadata, provider и provider connection string. Первый параметр задает ссылки на файлы CSDL, SSDL и MSL моделей. Все эти три файла хранятся в папке edmxResourcesToEmbed(найдите ее в дереве каталогов проекта) и представляют собой XML-файлы, описывающие соответственно: CSDL - концептуальную(объектную) модель в терминах бизнес-уровня, SSDL - схема хранения (реляционная схема), MSL - схема сопоставления (то есть связи между элементами CSDL и SSDL). Собственно все эти XML-файлы объединены в один с расширением EDMX.

Параметры provider и provider connection string задают как раз привычную нам строку подключения к БД.

Конструктор класса MyEFModelContainer можно вызвать также совсем без параметров, тогда по умолчанию строка подключения будет взята из App.config и станет равна той строке подключения, для которой собственно генерировался изначально DDL-скрипт.

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

Итак, теперь у нас есть контейнер данных, который помимо огромного количества прочих полезностей, содержит в себе три коллекции: Users, Groups, Rights - это те самые коллекции, ради которых собственно все и затевалось. Операции, производимые нами над этими коллекциями, автоматически (ну или почти автоматически) отображаются в базу данных, добавляя, удаляя или изменяя строки в соответствующих таблицах. Попытка чтения из коллекции приведет к выполнению SELECT-запроса к соответствующей таблице.

Пока наши таблицы пусты попробуем добавить в них некоторые данные. Пусть мы хотим, чтобы существовали два пользователя: chitatel и pushkin. Первый по статусу положено только чтение статей, второму - и чтение и запись. Понятно, что никаких статей у нас пока нет, важно только само разграничение прав на операции. При этом chitatel принадлежит группе "Читатели", а pushkin - группе "Писатели". Таким образом нам нужно создать два права: "Читать статьи" и "Редактировать статьи"; две группы: "Читатели" и "Писатели"; двух пользователей: chitatel и pushkin. А также - создать между ними корректные связи. Приведу сразу кусок кода, который надо выполнить единожды для того, чтобы создать все необходимые записи в таблицах.

// Создаем объекты прав
Right canRead = new Right()
{
  Description="Читать статьи",
};
Right canWrite = new Right()
{
  Description="Редактировать статьи",
};
// Создаем объекты групп
Group groupReaders = new Group()
{
  Name = "Читатели"
};
Group groupWriters = new Group()
{
  Name = "Писатели"
};
// Присваиваем группам соответствующие права
groupReaders.Rights.Add(canRead);  // читатели могут только читать
groupWriters.Rights.Add(canRead);  // писатели могут и читать
groupWriters.Rights.Add(canWrite); // и писать

// Создаем объекты пользователей и заносим их в соответствующую группу
User userChitatel = new User()
{
  Login = "chitatel",
  Registered = DateTime.Now,
  Group = groupReaders
};

User userPushkin = new User()
{
  Login = "pushkin",
  Registered = DateTime.Now,
  Group=groupWriters
};

// Теперь все эти существующие исключительно в памяти объекты
// добавляем в соответствующие коллекции контейнера
using (MyEFModelContainer cnt = 
  new MyEFModelContainer("name=MyEFModelContainer"))
{
  cnt.Rights.AddObject(canRead);
  cnt.Rights.AddObject(canWrite);
  cnt.Groups.AddObject(groupReaders);
  cnt.Groups.AddObject(groupWriters);
  cnt.Users.AddObject(userChitatel);
  cnt.Users.AddObject(userPushkin);
  // И финальный аккорд - сохраняем все изменения в БД
  cnt.SaveChanges();
}

Colored with dumpz.org

 После выполнения приведенного кода мы получим вот такие данные в таблицах: рисунок.

Рассмотрим теперь алгоритм выборки данных из контейнера. Я для этих целей буду использовать язык встроенных запросов LINQ.Предположим, что некий пользователь вошел в систему, и нам нужно определить, имеет ли он право редактировать статьи. То есть мы должны по имени пользователя получить его группу и посмотреть, имеет ли эта группа соответствующее право.

Для этого мы выполним следующий код:

            using (MyEFModelContainer cnt = 
                     new MyEFModelContainer("name=MyEFModelContainer"))
            {
                var check = from u in cnt.Users
                            where u.Login == "pushkin" && 
               u.Group.Rights.Any(f => f.Description == "Редактировать статьи")
                            select u;
                Console.WriteLine(check.Count());
            }

 Дословно, LINQ-запрос выбирает из БД всех пользователей, имеющих заданный логин(то есть единственного пользователя), и в правах группы в поле Description имеющих содержимое "Редактировать статьи". Если такой пользователь существует, то check.Count() == 1, а значит пользователь имеет требуемое право.

Текст SQL-запроса, выполненного в БД, выглядит так:

SELECT 
[GroupBy1].[A1] AS [C1]
FROM ( SELECT 
 COUNT(1) AS [A1]
 FROM [dbo].[Users] AS [Extent1]
 WHERE (N'pushkin' = [Extent1].[Login]) AND ( EXISTS (SELECT 
  1 AS [C1]
  FROM  [dbo].[GroupRight] AS [Extent2]
  INNER JOIN [dbo].[Rights] AS [Extent3] ON [Extent2].[Rights_Id] = [Extent3].[Id]
  WHERE (N'Редактировать статьи' = [Extent3].[Description]) AND ([Extent1].[Group_Id] = [Extent2].[Groups_Id])
 ))
)  AS [GroupBy1]

Colored with dumpz.org

 Здесь мы видим безобразный SELECT FROM SELECT отягощенный EXISTS-ом и INNER JOIN-ом. На мой взгляд, запрос далеко не оптимален. Немного упростить запрос, убрав из него INNER JOIN можно, если искать права не по названию ("Редактировать статьи"), что в любом случае являет плохим тоном, потому что зависит от способа написания названия права, а искать по Id права, ведь согласитесь сопоставление ID и DESCRIPTION в нашей базе всегда будет сохраняться. Таким образом, упрощаем LINQ-запрос:

var check = from u in cnt.Users
  where u.Login == "pushkin" && 
    u.Group.Rights.Any(f => f.Id == 2)
  select u;

 И получаем слегка укороченный SQL-запрос:

SELECT 
[GroupBy1].[A1] AS [C1]
FROM ( SELECT 
 COUNT(1) AS [A1]
 FROM [dbo].[Users] AS [Extent1]
 WHERE (N'pushkin' = [Extent1].[Login]) AND ( EXISTS (SELECT 
  1 AS [C1]
  FROM [dbo].[GroupRight] AS [Extent2]
  WHERE (2 = [Extent2].[Rights_Id]) AND ([Extent1].[Group_Id] = [Extent2].[Groups_Id])
 ))
)  AS [GroupBy1]

Colored with dumpz.org

 Я думаю, что на начальном этапе создания проекта, когда таблицы будут еще не слишком большими, подойдет и этот запрос, в дальнейшем же мы просто будем выносить все часто используемые не слишком оптимальные запросы в отдельные оптимизированные хранимые функции и процедуры. К счастью в Entity Framework 4 заложена возможность вызова хранимых процедур и функций, и не просто их вызова, а даже использования их в LINQ-запросах, что согласитесь очень хорошо.

Итак мы научились создавать модель данных, генерировать из нее схему данных, создавать сущности и делать из них выборку.

В следующей статье я планирую коснуться изменения (UPDATE) сущностей и изменения схемы данных (ALTER), создания и использования хранимых функций и процедур.

Проект можно скачать здесь test1

RU-Center отдает деньги за купленные в зоне .РФ домены

Покупка компании Ru-Center должна завершиться к концу 2011 года, когда АНО "РСИЦ" будет ликвидировано, а все клиенты вместо со своими доменными именами перейдут под управление ЗАО "Региональный сетевой информационный центр". Напомню, что группа Hosting Community, покупает Ru-Center, а точнее две из трех, входящих в Ru-Center компании - ЗАО "РСИЦ" и ООО "НИК Медиа".

Компанию АНО "РСИЦ" купить невозможно, потому что она является некоммерческой организацией, а значит купить ее невозможно. На данный момент осталось перевести из АНО в ЗАО более 200 тысяч доменов. Перевод клиентов под крыло группы Hosting Community будет происходить постепенно - при попытке продлить доменное имя клиенту будет предложено перевести домен в ЗАО "РСИЦ" либо уйти к другому регистратору.

Федеральная Антимонопольная Служба продолжает разбираться с сомнительным проведением доменных аукционов в зоне .РФ, пытаясь найти в нем признаки картельного сговора. Если подозрения подтвердятся, то РСИЦ будет оштрафован. Но что делать тем, кто купил втридорога домен в зоне .РФ и планирует от него отказаться.

Александр Панов (управляющий партнер группы Hosting Community) утверждает, что такие люди могут получить назад свои деньги, вернув домен регистратору. Деньги им будет возвращать непосредственно Ru-Center, так как HC считает, что не обязан отвечать за обязательства взятые до них (Что на мой взгляд весьма странно, ведь обычно компания покупается вместе со своими долгами и обязательствами. Или я не прав???)

Несостоявшиеся покупатели проигравшие аукцион, не могут претендовать на домены, выигравшие владельцы которых не планируют отказываться от своих доменов.
Hosting Community не боится санкций со стороны ФАС за превышение доли занимаемого рынка после поглощения Ru-Center, так как считает хостинг телематической услугой, а значит делит этот рынок вместе с крупными операторами сотовой связи. Что ж, время покажет...

Приглашаем обсудить эту новость.

Птичка разжирнела

Лавры Youtube - крупного видеохостера, не дают покоя сервису микроблогов Twitter, и вот уже и они построили у себя фото и видеохостинг.

И если открытие фотохостинга был ожидаемым событием, то возможность хранить видео стала новостью. Так что очень скоро это существенно скажется на бизнесе таких конкурентов, как Twitpic и Yfrog, ведь вполне можно ожидать конкретных недружественных действий Twitter против сервисов сторонних компаний.

Совсем скоро пользователи твиттера, работающие со своих мобильных устройств, получат обновленные версии приложений, поддерживающие новые функции сервиса.

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

 Приглашаем обсудить эту новость

Новости... Ведущие разработчики браузеров планируют отказаться от привычной всем пользователям адресной строки. Что будет вместо нее? Приглашаем к обсуждению на нашем сайте.

Пул данных

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

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

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

Допустим, есть набор некоторых данных и несколько хорошо задокументированных классов.

$data = array();

$data['a'] = 1;
$data['b'] = 2;
$data['c'] = 3;
$data['d'] = 4;

class A
{
    private $a = 0;
    private $b = 0;

    public function __construct($a, $b)
    {
        $this->a = $a;
        $this->b = $b;
    }

    public function process_data()
    {
        //.......
    }

    public function return_data()
    {
        $arr = array();

        $arr['a'] = $this->a;
        $arr['b'] = $this->b;

        return $arr;
    }
}

class B
{
    private $arr = array();

    public function __construct($a, $b)
    {
        $this->arr['a'] = $a;
        $this->arr['b'] = $b;
    }

    public function process_data()
    {
        //.......
    }

    public function return_a()
    {
        return $this->arr['a'];
    }

    public function return_b()
    {
        return $this->arr['b'];
    }

}

class C
{
    private $arr = array();

    public function __construct($arr)
    {
        $array = array();

        $array[0]['c'] = $arr['c'];
        $array[1]['d'] = $arr['d'];

        $this->arr[0]['a'] = $arr['a'];
        $this->arr[0]['b'] = $arr['b'];
        $this->arr[1]['xxx'] = $array;

    }

    public function process_data()
    {
        //.......
    }

    public function return_data()
    {
        return $this->arr;
    }
}

 Colored with dumpz.org

Ну как, осознали? А теперь представим, что у нас есть таких классов не три, а триста. Все эти классы работают абсолютно нормально. Они все получают некоторый набор данных, обрабатывают его и возвращают результаты. Результаты могут содержать уже изменённые данные, могут содержать первоначальные данные, а могут вообще не содержать никаких данных. Точно та же картина и при инициализации этих классов - данные всё те же, а форматы инициализации объектов разные. В реальной программе такое может произойти, например, с личными данными пользователя. Может существовать много классов, которым нужно использовать данные пользователя. Какой-то класс запросит все данные. Какому-то будет достаточно только электронного адреса и он запросит в конструкторе инициализацию объекта строковой переменной. Одно дело, если вы в существующей системе создаёте новый класс, берёте данные из базы и как-то их обрабатываете. Совсем другое, когда вы вынуждены пользоваться уже обработанными данными и возникает ситуация, когда из нескольких объектов нужно получить одни и те же данные, и у этих данных разный формат. Конечно же вы получите, обработаете и вернёте данные. Снова в новом формате. И так до бесконечности. Рано или поздно, поддерживать систему станет практически невозможно. Даже если всё отлично задокументировано.

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

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

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

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

В-четвёртых, нужно чётко понимать, что пул данных - это не мусорка, а поэтому не стоит хранить в нём временные переменные. Например, такое использование пула данных является недопустимым -

class A
{
    private function foo()
    {
        $a = 5;
        $data_pool->set_data($a);
    }

    private function bar()
    {
        $a = $data_pool->get_data('a');
    //$a == 5;
    }
}

 Colored with dumpz.org

И в-пятых, сам пул данных не имеет права данные изменять. Что положили, то и забрали. Хотя, если некоторый класс считает, что данные в пуле устарели и решает их перезаписать, пул должен с этим согласиться.

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

Но хватит слов и перейдём к делу. Давайте разработаем простенький пул данных, который будет иметь уровни доступа и предоставлять пользователю операции записи и чтения. Итак, у меня получилось следующее -(Исходный код примера "Пул данных" на PHP вы можете загрузить по ссылке Пул данных. Реализация на PHP.)

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

Резюмируя, нужно сказать, что пул данных является стандартом де-факто для сложных веб-систем, которые пишутся более чем одним программистом. Надеюсь, вы сегодня узнали что-то новое и интересное. Всем удачи.

Другие интересные статьи, посвященные веб-разработке, расположены на сайте "Веб-разработка? Это просто!". Добро пожаловать.

Я уверен, что скоро персональные компьютеры повторят судьбу динозавров. Мейнфреймы, cloud-computing, лэптопы, мобильные устройства и нестандартные гаджеты с доступом к паутине рано или поздно окончательно победят большие и неповоротливые ящики, напичканные железяками. Обычные PC останутся только в малобюджетных гос. организациях и ВУЗах и, однажды, какой-нибудь всемирный консорциум типа ISO объявит об отмене поддержки стандартов для писюков. Рынок PC пережил свой пик в конце 90-хх - начале 2000-хх и теперь из года в год показывает стабильное снижение продаж. Вычислительные мощности топовых ноутбуков вполне сопоставимы с вычислительными мощностями топовых PC. Конечно, топовые PC продолжают выигрывать, но для абсолютного большинства бизнес-пользователей производительности мобильных платформ хватает с огромным запасом. Последний форпост PC - это геймеры. Но, рано или поздно, они окончательно пересядут на специализированные игровые консоли, а для чата и сёрфинга заменят свои писюки на ноутбуки. Последняя проблема в мобильных устройствах - ёмкость батареи. Рано или поздно эта проблема будет разрешена и PC переместятся в пыльные музеи кремниевых микросхем.

Но пока этого события не произошло, посмотрим на всю нашу деятельность критическим взглядом. Сколько сайтов сегодня имеет мобильную версию? Имеет ли сайт вашей компании мобильную версию? Имеет ли мобильную версию ваш хоумпейдж? Или блог? Насколько удобно вам работать с удалённым ресурсом с помощью телефона? Вряд ли на все эти вопросы можно ответить однозначное и твёрдое да. Конечно, огромные порталы уже давно имеют свои мобильные версии. Но бизнес рунета почему-то шевелится крайне медленно. Моя компания даже "дарит" мобильную версию сайта в случае хорошего и жирного заказа. Хотя, с точки зрения бизнеса, владельцы доменов должны давным давно обратить внимание на сайты, оптимизированные для мобильных платформ.

Представим себе обычный интернет-аукцион. Вы делаете бид. И уезжаете по делам. Вам очень хочется заполучить этот лот. Но ваш бид побили. Конечно, вы получите уведомление на email, но если ваш телефон не настроен на автоматическое получение почты, вам будет крайне проблематично ответить. С другой стороны, если аукцион не имеет мобильной версии, пользователь может просто отказаться от бида по многим причинам - громоздкое приложение на сравнительно маленьком дисплее, сравнительно медленный коннект и мелкие элементы управления, куча джаваскриптов, которые будут открываться на телефоне в новых окнах и жутко раздражать пользователя, в конце-концов, недружелюбные пользовательский интерфейс. Ведь то, что дружелюбно на огромном мониторе, абсолютно враждебно на маленьком телефонном экранчике. А между тем, отказ от бида - это прямой убыток, т.к. владелец аукциона получает процент от сделки. Звучит не очень радостно.

Окей, хватит лирики. Посмотрим на решение.

Специализированных решений пока два - WAP и PDA сайты. Основное отличие в том, что WAP - это протокол, а PDA - это просто вёрстка, заточенная под мобильные устройства. Что же выбрать? Давайте посмотрим.

Итак, WAP.
Во-первых, разработка WAP-сайта будет стоить дороже, чем разработка PDA-версии. Просто потому, что все верстальщики отлично знают HTML, xHTML, XML и т.п., но мало кто из них знает WML. Конечно, WML мало чем отличается от обычного HTML, но тем не менее. Итак, разработчик должен знать WML для разработки WAP-сайтов. А значит, стоимость такого более квалифицированного разработчика будет выше. И стоимость сайта будет выше.

Дальше - сам протокол. Принципиально протокол WAP ничем не отличается от обычного HTTP. Просто разработчики мобильных устройств вместе с бюрократами решили стандартизировать передачу данных по беспроводному протоколу, придумали WAP и все бы ничего, если бы ОпСоСы из каких-то абсолютно неведомых соображений не решили, что строка байт полученная по протоколу WAP должна стоить в разы дороже той же самой строки, полученной по протоколу HTTP посредством одной и той же технологии (например, GPRS). Лично я подозреваю, что этот финт ушами был рассчитан исключительно на непрофессионалов, с которых можно просто содрать деньги за ещё одно непонятное слово, в данном случае - WAP.

Как пример, вот стоимость одного мегабайта у украинского ОпСоСа "Киевстар GSM" на момент написания статьи:

WAP: $1.6
HTTP: $0.8
Специальная услуга доступа в интернет с человеческими ценами: $0.63/сутки + $0.0063/мегабайт.

Исходя из этой сетки цен, можно вполне уверенно предположить, что фактически передача одного мегабайта стоит недороже $0.01 (сравниваем с WAP).

Нетрудно сделать выводы, что вашей версией WAP сайта будут пользоваться только полные отморозки-мажоры.

К тому же, произошло то, что и должно было произойти - если WAP пока ещё поддерживается, то всё больше производителей мобильных девайсов отказываются от поддержки WML в пользу xHTML во встроенных браузерах. Вопрос - зачем передавать по специализированному протоколу всё те же HTML данные? Ответ очевиден.

Резюмируя всё выше сказанное, можно утверждать, что создание WAP версии сайта неоправданно дважды - экономически, т.к. существует вполне реальный дефицит на WML-специалистов, и практически - т.к. WAP-версией сайта просто никто не будет пользоваться. В то же время, у пользователя существует определённый спектр проблем, которые возникают при попытке воспользоваться обычным сайтом с мобильного девайса. А это значит, что разработчики должны эти проблемы решать. На вопрос, решать ли эти проблемы в принципе, ответ вполне однозначен - решать, т.к. сегодня количество проданных смартфонов в два раза превышает количество проданных персональных компьютеров. Решение проблемы лежит не только в технической области, но и в экономической, а, значит, бизнесу также необходимо обратить самое пристальное внимание на свои веб-ресурсы.

Переменные переменных. Зачем они нужны.

Всем привет. Сегодня мы поговорим о переменных переменных и выясним, зачем они всё таки нужны (или не нужны).

В самом простом виде переменные переменных показаны в справке PHP. А именно -

$a = 'hello';
$$a = 'world';
echo $a . ${$a};

Подобная кривая конструкция выдаст на экран hello world. Другими словами, ${$a} эквивалентна вызову $hello. Не правда ли.. ужасно? Добавим сюда проблему неоднозначности, которая возникает при попытке обратиться к элементам массива (это подробно описано в справке по адресу http://ua.php.net/manual/en/language.variables.variable.php), добавим сюда возможность добавлять к имени переменной любое количество знаков доллара, о которой обычно не пишут в учебниках, и возникнет вполне закономерное недоумение - зачем это вообще нужно?

Самое главное правило, которого должен придерживаться любой разработчик в любом проекте - код пишется для людей, а не для машин. Это правило помимо негласного этикета в среде профессионалов в виде комментариев и отступов, ещё и экономически обоснованно. Дело в том что сегодня разработка ПО стремительно дешевеет (не без помощи демпинга индусов). Прямым следствием является то, что поддерживать код должно быть дешевле, чем его писать. Т.о. становится понятно, что читабельный, понятный и простой в понимании код, куда как более ценен, чем процессинг формы на Brainfuck'e (кто не в курсе, пусть насладится http://en.wikipedia.org/wiki/Brainfuck), пусть даже на Brainfuck'e этот процессинг работает на 0.0001 секунду быстрее.

Добавим сюда огромные вычислительные возможности современных серверов, которые могут прожевать мегаметры самого бездарного кода в течение секунды и станет понятно, что деньги, затрачиваемые на поддержку, должны быть минимальными. Разработчик должен иметь возможность спокойно и быстро разобраться в коде, написанном соседней командой, даже через пару лет после финального релиза проекта. Реалии PHP вполне это позволяют - всё таки это скриптовый язык, а не ассемблер.

Продолжение статьи "Переменные переменных, зачем они нужны?", а также другие интересные статьи, посвященные веб-разработке, Вы можете прочитать на сайте "Веб-разработка? Это просто!".

Пивот или сводная таблица

Всем привет. Сегодня мы коснёмся одной очень интересной темы, которая очень слабо освещена в рунете. Тема эта больше теоретическая, и, скорее всего, в обычных проектах вы с этим не столкнётесь никогда, но уж если столкнётесь и не будете знать, что перед вами, пара-тройка бессонных ночей вам гарантированна. С другой стороны, если перед вами возникнет задача, где можно использовать пивот, вы сможете резко повысить производительность вашей системы. А для веб производительность всегда была критична. Попробуем же потратить пол часа сейчас и отлично выспаться потом, когда-нибудь в будущем :)

Итак, пивот. Что это такое и с чем его едят? Скажу сразу, к пиву это не имеет никакого отношения. А имеет отношения к реляционным базам данных, например, к MySQL. Пивот - это разворот таблицы. Или таблица разворота. Вот видите, это уже, практически, пивот. Придумали эту штуку два оч. умных дядьки - Бил Джелен и Майк Александер. Подробнее об истории пивота можно посмотреть в английской википедии (http://en.wikipedia.org/wiki/Pivot_table).

Приведём пример, чтобы понять, что такое пивот, т.к. без примера и на словах понять это практически невозможно (если Эйнштейн не был вашим дедушкой, а Тьюринг - братом, конечно).

Пусть есть исходная MySQL таблица, которая хранит результаты экзаменов -

CREATE TABLE exams (
  pkey int(11) NOT NULL auto_increment,
  name varchar(15),
  exam int,
  score int,
  PRIMARY KEY  (pkey)
);

+------+------+------+-------+
| pkey | name | exam | score |
+------+------+------+-------+
|    1 | Bob  |    1 |    75 |
|    2 | Bob  |    2 |    77 |
|    3 | Bob  |    3 |    78 |
|    4 | Bob  |    4 |    80 |
|    5 | Sue  |    1 |    90 |
|    6 | Sue  |    2 |    97 |
|    7 | Sue  |    3 |    98 |
|    8 | Sue  |    4 |    99 |
+------+------+------+-------+

Это обычная плоская таблица MySQL. Автоинкрементный первичный ключ нас вообще не интересует. В остальных колонках хранится номер экзамена и количество баллов, которые студент по имени name умудрился набрать (судя по всему, Sue вообще никогда не прогуливает). Понятно, что exam может быть в свою очередь внешним ключом для ссылки на другую таблицу с названием экзаменов, с экзаменаторами и т.д. Нам это не интересно.

При пивоте по экзамену результирующая таблица будет выглядеть так -

+------+-------+-------+-------+-------+
| name | exam1 | exam2 | exam3 | exam4 |
+------+-------+-------+-------+-------+
| Bob  |    75 |    77 |    78 |    80 |
| Sue  |    90 |    97 |    98 |    99 |
+------+-------+-------+-------+-------+

Сразу видно, насколько эта таблица полезнее. Например, если эти данные вернуть в PHP приложение, то обладая тем же набором данных мы сделаем всего лишь две итерации цикла для выборки всех данных из таблицы. Для первой плоской таблицы нам бы пришлось гонять цикл while все восемь раз. Согласитесь - прирост производительности в 4 раза - серьёзный аргумент за то, чтобы задуматься об использовании такого приёма. Как же получить такую пивот-таблицу? Для начала рассмотрим нематематический способ. Он ничем не хуже математического, но изначально пивот был изобретён для осуществления каких-то более осмысленных действий над данными, чем простая выборка, например - вычисление средних значений, вычисление разниц, использование каких-нибудь статистических функций с выбранными данными и т.п.

Продолжение статьи "Пивот или сводная таблица" а также другие статьи, посвященные веб-разработке, Вы можете прочитать на сайте "Веб-разработка? Это просто!".

Отличная спецификация про HTML5 для разработчиков

По ссылке HTML5. A technical specification for Web developers доступна отличная спецификация по HTML5 для веб-разработчиков. В отличие от полной HTML5-спецификации из этой редакции убрана вся информация, знать которую нужно только разработчикам браузеров. Основополагающими отличиями данной редакции являются читабельность и удобная навигация.

Регистратор GoDaddy продает домены по 1.18$

Регистратор GoDaddy объявил акцию - регистрация и трансфер домена в зоне .COM, .US, .MOBI, .BIZ, .NET, .ORG, .CA, .CO.UK, .IN всего за 1.18$.
Акция действует до первых 10000 доменов или до 20 марта. Оплата регистрации только по карте, с одного аккаунта можно зарегистрировать только один домен.

Букмарклеты или как скачать аудиофайлы с сайта vkontakte?

Сегодня я собираюсь рассказать про одну интересную технологию, как мне кажется, с большим будущим. Называется эта технология bookmarklets(букмарклеты). Букмарклет - это маленькая JavaScript-программа, оформленная в виде javascript-ссылки и вызываемая как браузерная закладка. Итак, мы знаем, что в атрибуте href гипертекстовой ссылки можно указать url любой существующей страницы, обычно url этот выглядит примерно так <a href='http://address.org/path/index.html'>ссылка</a>, в данном случае http: - это указание протокола обмена, а все остальное - указание сервера, пути к файлу, и имени файла, к которому обратится браузер после клика на ссылке. Так вот, существует ряд протоколов, таких как, например, http: (протокол гипертекстового обмена), ftp:(протокол обмена файлами), file:(протокол загрузки локальных файлов пользователя).

Помимо этого существует еще один интересный протокол javascript:, который мы и будем использовать для создания букмарклетов. Выглядит это примерно так:

<a href='javascript:alert('Hello, world');'>букмарклет</a> при щелчке по этой ссылке, выполнится команда alert('Hello, world'); Проверьте, как это работает.

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

Попробуем немного усложнить нашу закладку, пусть тепреь она выводит адрес документа из которого она вызвана. Вот этот букмарклет:

<a href='javascript:alert(document.location);'>Адрес текущей страницы</a>.

Добавьте эту ссылку (Адрес текущей страницы) в закладки и вызовите ее, открыв предварительно в браузере какую-нибудь интернет-страницу, например сайт Яндекса. Вы увидите всплывающее оповещение с указанием адреса текущей страницы. Из этого можно сделать один очень важный вывод: букмарклет, вызванный из браузера, как закладка, выполняется в контексте текущей, открытой в браузере страницы. А этот факт дает нам неограниченный доступ к изменению данных на странице, и к извлечению из страницы любых данных, вплоть до полной замены содержимого этой страницы.

К сожалению, длина скрипта, сохраняемого в закладке ограничена. Причем, для разных браузеров она разная. Не углубляясь в различия между браузерами, можно сказать, что длина эта ограничена для различных браузеров от 488 до 2084 символов, что не может не огорчить. В принципе, для несложных букмарклетов нам хватит и этой длины, но что делать, если нам хочется большего? Что если мы хотим написать скрипт, который производит достаточно сложную обработку загруженной страницы, и в 2 кБ скрипта нам никак не уложиться?

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

Созданием этого скрипта мы сейчас и займемся. Но для начала замечу вот что. Какой бы скрипт мы ни создавали, практически всегда в нем мы будем объявлять создание новых функций и новых переменных. А создаваться они будут в контексте загруженной пользователем страницы, где до нас уже могут существовать какие-либо переменные и функции. Понятно, что мы никак не можем предугадать, какие имена будут у этих переменных, а значит, создавая свои собственные, мы можем случайно переопределить уже существующие переменные, внеся тем самым непредсказуемые изменения в логику работы пользовательских скриптов. Таким образом, запустив букмарклет, помимо его полезной работы, мы можем получить и совершенно непредсказуемые побочные явления, связанные с перопределением переменных.

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

Продолжение статьи "Букмарклеты или как скачать аудиофайлы с сайта vkontakte?" и многие другие статьи про тонкости веб-разработки Вы можете прочитать на сайте "Веб-разработка? Это просто!".

AJAX при помощи DataContractJsonSerializer и ashx-handler

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

1. Тип клиентской JS-библиотеки
2. Тип серверного ответчика
3. Способ сериализации данных
4. Тип передаваемых данных

Расскажу подробнее о каждом из пунктов.

1. Тип клиентской JS-библиотеки.

   Это тот скрипт, который работает в браузере пользователя. Какую бы библиотеку Вы не использовали, в недрах ее для асинхронного обмена данными в любом случае будет использоваться объект XmlHTTPRequest. Я лично пользовался такими библиотеками как: ExtJS, jQuery, prototype.js, ATLAS. Сложно сравнивать эти библиотеки, все они хороши, каждая по своему.

2. Тип серверного ответчика.

   Прежде всего серверный ответчик характеризует язык серверной реализации, это может быть PHP, ASP.NET, Java, Ruby, Python и много других страшных слов. :) В каждом языке есть свои типы серверных ответчиков. Говоря про ASP.NET, я могу выделить WebServices (*.asmx), Generic Handlers (*.ashx).

3. Способ сериализации данных.

   Их можно сериализовать "вручную", то есть простой конкатенацией строк, можно использовать встроенные в серверную платформу объекты, например DataContractJsonSerializer, который имеется в ASP.NET.

4. Тип передаваемых данных.

   Данные можно передавать в собственном формате, можно в виде JSON-строки, XML-строки, или же передавая строку с готовой HTML-разметкой. Вариантов масса, выбор зависит от контекста задачи.

В данной статье я собираюсь рассмотреть вариант релизации AJAX-обмена на основе компонентов:

1. Клиентская библиотека - jQuery,
2. Серверный ответчик - Generic Handler (*.ashx),
3. Способ сериализации - DataContractJsonSerializer,
4. Тип данных - HTML-разметка, упакованная в JSON-строку.

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

Продолжение статьи "AJAX при помощи DataContractJsonSerializer и ashx-handler" и другие полезные статьи, посвященный веб-разработке Вы можете прочитать на сайте "Веб-разработка? Это просто!"

DOM: вытаскиваем текст вне тегов

Данная публикация открывает новую рубрику в блоге. Рубрика называется "Кратко". В ней я буду публиковать совсем кратенькие статьи - рецепты, темы для которых чаще всего буду брать из статистики поискового трафика. То есть, если я вижу, что человек пришел на мой сайт по некоему запросу, и ответа на вопрос на моем сайте нет, то я буду писать на них ответы и может когда-нибудь мой ответ пригодится.

Анализируя поисковый трафик, я обнаружил вопрос "вытащить текст вне тегов", делюсь рецептом. Собственно, каждая ситуация уникальна, но в общем случае, нужно отыскать в DOM-структуре некий строго определенный элемент и уже относительно него отыскать нужный нам текст.

В нашем случае документ представляет собой два дива с заданными строго идентификаторами, между которыми расположен искомый текстовый элемент. При помощи getElementById мы на ходим элемент div1, а затем при помощи nextSibling добираемся до текстового узла, ведь он стоит следующим в DOM-структуре. Получить его значение можно при помощи свойства nodeValue.

Вот и весь рецепт.

<html>
<head>
 <title>Hello!</title>
 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
 <script type="text/javascript">
 function getText()
 {
 var div1 = document.getElementById("div1");
 div1.nextSibling.nodeValue = "Поменял текст";
 }
 </script>
</head>
<body>
<div id="div1">Предшествующий
блок</div>
Это текст я хочу получить
<div id="div2">Замыкающий блок</div>
<input type="button" value="Start!" onclick="getText()">
</body>
</html>

DIV всплывающий поверх flash-баннера

В процессе создания сайтов, столкнулся однажды с проблемой выражаемой в том, что flash-баннер, размещенный на странице, закрывает собой всплывающий DIV содержащий в себе меню навигации.

Сам этот DIV имеет z-index больше нуля, и когда на странице нет никакой Flash-анимации, этот DIV плавает поверх страницы. Однако, как только появляется Flash-баннер, то баннер этот рендерится поверх любых плавающих DIV-ов.

Как и все гениальное, решение оказалось простым. Достаточно тегам OBJECT и EMBED добавить атрибут wmode со значение opaque.

Выглядеть это должно как-то так:

<OBJECT wmode="opaque" ...>
<EMBED ...>
<PARAM name="wmode" value="opaque">
</EMBED>
</OBJECT>

А связано это с тем, что по умолчанию, параметр этот принимает значение window, а это говорит браузеру, что флешку необходимо отрисовывать поверх страницы и всего, что на ней находится. Другие значения параметра wmode - opaque и transparent. Последний ко всему прочему позволяет задавать прозрачный фон для DIV'а, отображаемого поверх флешки. Учтите, что подобные игры с прозрачностью могут заметно ухудшать производительность работы браузера.

Кросдоменная передача данных между html-страницами

Итак, представим себе ситуацию, что на некотором сайте в некоторой форме есть поле, в которое нужно ввести логин пользователя, но не свой собственный, а чужой логин, предположим, пользователя, которого надо добавить в друзья или в черный список. Но посетитель может не помнить наизусть, как пишется этот логин, а потому мы сделаем так, чтобы он мог выбрать его из списка, причем список этот должен открыться в отдельном окне и там помимо списка логинов пользователей должны отображаться еще и их фотографии, ФИО, возраст и т.д. Предположим, что мы даже создали такую страницу со списком пользователей. Возникает вопрос - как передать из одного окна браузера в другое окно некоторые данные (в данном случае это - логин пользователя)?

Справочник по JavaScript и объектной документной модели DOM говорит нам, что для открытия нового окна нужно использовать метод window.open(), а для доступа из "дочернего" окна в "родительское" (то есть то, которое и породило новое окно) нужно использовать указатель opener.

Здесь все просто, и я не стал бы писать эту статью, если бы хотел рассказать только про это.

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

"Что тут сложного?" - спросите вы. А давайте попробуем.

Продолжение статьи "Кросдоменная передача данных между html-страницами", а также другие статьи, посвященные веб-разработке, вы можете прочитать на сайте "Веб-разработка? Это просто!"

В нашем блоге появился форум.

В нашем блоге появился форум.

Именно так.

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

Если вам есть что сказать – пишите на форуме. Добро пожаловать.

Реализация чата на ASP.NET с использованием Long Polling

Бродя по просторам интернета, на одном из сайтов я увидел простой чат. Просмотрев страницу в FireBug я понял, что никакими апплетами там и не пахнет, а значит чат реализован на простом JavaScript.

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

И встал передо мной вопрос - как они это сделали? Как они обеспечили такую высокую скорость отдачи свежих данных? Ведь веб-сервер на то и сервер, что может лишь отвечать на запросы пользователя, но уж никак не самостоятельно инициировать запросы.

Непродолжительный поиск по интернетам дал мне ответ. И ответ этот "Long Polling", а встречается еще и другое название технологии - Comet.

Итак, как же это работает?

По сути, это все тот же старый добрый AJAX, и использование объекта XmlHttpRequest. С одной большой разницей, заключенной на серверной стороне. Разница состоит вот в чем. Клиент посылает XHR-запрос и длительное время ожидает ответа сервера. А "длительное время" отклика обеспечивает сам сервер, который не сразу отдает данные клиенту, а лишь только тогда, когда у него в очереди появляются свежие данные, то есть когда ему действительно есть что сказать.

Клиент, дождавшись ответа, обрабатывает его (например, отображает сообщение на странице), а затем, без промедления, снова запрашивает сервер. И снова ждет.

Если же подав запрос клиент так и не дождался ответа из-за таймаута, то он снова запрашивает сервер. А откуда этот таймаут? А просто серверу нам нечего ответить, вот он и не отдает клиенту результат запроса. Ждет. Но не дождавшись, разрывает соединение по таймауту. Такая вот несложная схема.

Это и называется Long Polling, то есть - длительный опрос.

Но от слов к делу. Сейчас мы изготовим серверную и клиентскую часть простого интернет-чата, построенного на описанной технологии. Мы подробно рассмотрим работу всего серверного и клиентского кода и даже в конце статьи получим ссылку на вполне работоспособный продукт. Сразу скажу, у него есть некоторые ограничения. Вы, например, не сможете его использовать в режиме сильной нагрузки, то есть наличии одновременно большого количества клиентов. В нем нет схемы очистки "потерянных" соединений. Это лишь работоспособный учебный пример. Все недостающие аспекты кода предлагаю вам на самостоятельную доработку.

Продолжение статьи Реализация чата на ASP.NET с использованием Long Polling вы можете прочитать на сайте Веб-разработка? Это просто!