Delphi в Интернет, блог Delphi программистов

В одном из постов в блоге я рассказывал про новый класс в проекте "Google API в Delphi" для авторизации в API по протоколу OAuth 2.0.

По большому счёту модуль для OAuth создавался для того, чтобы использовать его в API, которые не поддерживают ClientLogin (в основном это новые API из Лаборатории). Но после известных событий в самом Google (см. "18 API Google псу под хвост…") этот модуль как-то затерялся, забылся т.к. тратить время над API, которые в любой момент могут быть объявлены несостоявшимися как-то не хотелось. Сегодня я решил снова вернуться к теме использования OAuth в Google и написать небольшой компонент Delphi, которые, наряду с уже имеющимися компонентом GoogleLogin позволит авторизовываться в любых API Google вне зависимости от того находится ли этот API в лаборатории или это стабильная версия, например, как Google Docs API 2.0.

Чтобы не повторяться дважды и не рассказывать об устройстве OAUth 2.0 для проектов гугла, советую Вам прочитать предыдущий пост на эту тему, тем более, что демка для компонента будет таже самая. Читать далее »

Продолжаю копаться в Google Documents List API. И сегодня на повестке дня – работа с деревом каталогов и документов Google Docs. В силу того, что список документов Google представляет собой ни что иное как хранилище данных GData или, говоря проще, большую базу данных, этот список имеет ряд особенностей в плане расположения и структурирования данных нежели простой каталог с документами на жестком диске компьютера.

В чем принципиальное отличие? Дело в том, что как и в любой базе данных, любую запись в хранилище Google можно однозначно идентифицировать по ключу. В Google Docs ключом может выступать как Resource ID (идентификатор ресурса) так и уникальное значение – ETag. И это обстоятельство дает нам такую редко используемую на практике, но тем не менее возможность, как создание на одном уровне вложенности нескольких документов или папок (коллекций) с одним и тем же названием, что. как известно, невозможно сделать стандартными средствами той же ОС Windows. Например, можно создать вот такую структуру коллекций документов:

Читать далее »

Как я уже упоминал, использование в своих программах Ribbon Controls для того "чтобы было красиво" не всегда оправдано. Более того для многих программ использование Ribbon просто излишне и может повлечь за собой массу проблем и неприятностей для вас, как для разработчиков. Как ни крути, а на данный момент новые компоненты Delphi имеют слишком много недоработок и слишком мало справочной информации для разработчиков, чтобы каждый из нас мог их спокойно использовать.  Что касается необходимости использования Ribbon Controls, то пока я могу найти только одну более-менее важную причину, чтобы кинуть на форму TRibbon - слишком большое количество элементов управления (элемнтов главного меню, кнопок и т.д.). Тогда может и стоит работать с Ribbon, т.к. с его помощью можно организовать довольно удобное расположение всех элементов управления и красочный вид для своей программы. Читать далее »

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

Писать лишние строки кода в программу для предания "псевдофункционала", занятие не благодарное. Самым распространенным примером, таких самоистязаний, пожалуй служит совмещение нескольких контролов в один. Так скажем поверх TaskBar "накладывают" всевозможные TrackBar-ы, ProgresBar-ы, и прочие радости жизни; скрытые Edit-ы также лепят поверх Label-ов, что-бы реализовать возможность "удобного" редактирования; ComboBox-ы совмещают со всем чем только не лень.

А ведь подобные нагромаждения не столько улучшают навигацию, сколько усложняют разработчикам жизнь, поскольку разобраться потом в сотворенном бывает довольно сложно. Решения этой проблемы в целом я конечно раскрыть не смогу, но постараюсь поделиться своим опытом на конкретном примере. Читать далее »

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

Все-таки как ни крути, а периодический обзор исходников, компонентов и готовых программ проводить следует хотя бы потому что:

1. Блог растёт и вместе с ним растёт суммарный объем исходного кода выкладываемого на суд посетителей и дабы не повторяться следует представлять состав своего "богатства"
2. Структурированная информация довольно хорошо помогает определиться с ближайшими целями и задачами, которые следует решать в блоге или вне его.
3. Информация предоставляемая в форме списка, каждый пункт которого сопровождается ссылкой на источник достаточно хорошо воспринимается посетителями.

В этом микро-обзоре мы рассмотрим всё что касается применения Delphi для Web. Что было разработано и что планируется разработать в ближайшем будущем. Читать далее »

Как известно, одной из составных частей аудита любого сайта является сбор сведений о нахождении сайта в базе поисковых систем.  При этом необходимо ответить на два простых вопроса: "Есть ли сайт в индексе поисковой системы?" и, если сайт находится в индексе, то "Какое количество страниц сайта находится в индексе?". На сегодняшний день можно выделить несколько поисковых систем, пользующихся большим спросом у пользователей (по данным SpyLog): Читать далее »