Категорія: CFML
Обучающие видео от Adobe
Adobe выложила в YouTube серию обучающих видео, которые составляют 9 часов курса Getting started with ColdFusion 2016. Всего 12 разделов:- Introduction
- Configuring your work environment
- Variables and data types
- Publishing database content
- Creating a drill down interface
- Insterting new data in the database
- Updating data
- Reusing Code
- The application framework
- Session management
- More security
- Building the site administration
Современные фреймворки для качественной разработки на Adobe Coldfusion
(Доклад на встрече .NET User Group Sevastopol 29 июля 2011г., офис компании Softserve, Севастополь)
Фреймворк - это кусок кода, который используется повторно для создания проектов на его основе. Это своеобразны шаблон проектов. Фреймворк призван ограничивать фантазию разработчика, ставить определенные рамки, но взамен фреймворк предлагает хорошие, проверенные архитектурные решения. Следуя вдоль линий, намеченных фреймворком, разработчик в результате получит предсказуемый результат и качественный "робастный" код.
Прежде чем рассказать о фреймворках для Coldfusion, напомним, что представляет из себя этот продукт. Adobe Coldfusion - это сервер приложений, написанный по спецификации JEE, и реализующий язык Coldfusion Markup Language (CFML). CFML - интерпретируемый язык, с помощью которого можно создать веб-сайты любой сложности. Кроме веб-сайтов для Интернета, с помощью Coldfusion легко создавать сайты для корпоративных сетей (Интранетов), благодаря хорошей интеграции с корпоративными серверами, работе с разными форматами данных и протоколов.
Coldfusion появился в 1995 году и обрел популярность во времена "бума дот-комов". В то время сайты делались вебмастерами на HTML, без привлечения скриптовых языков, а единственной опцией было использование Perl. Последний нельзя считать легким для изучения и применения вебмастером - человеком с преимущественно дизайнерским набором навыков. Ответом на это было сделать простой теговый язык наподобие HTML, для быстрого освоения и разработки сайтов. После краха доткомов, Coldfusion несколько растерял популярность на волне популярности ASP и PHP, но выжил благодаря хорошей адаптации в корпоративной среде и в государственном аппарате США. Сейчас происходит второе рождение Coldfusion, и ему есть что предложить миру.
Скорость и легкость разработки на CFML имеет свои обратные стороны. Зачастую, код писался слишком быстро, чтобы выйти на рынок быстрее конкурентов. Качество было забыто, и зачастую код писался непрофессиональными программистами, что не могло отразиться на качестве. Отсутствие общей архитектуры проекта и организации кода, привело к появлению "спагетти"-кода (длинные куски кода, связанные с другими кусками в неразрешимые клубки), в котором сложно разбираться, исправлять ошибки и расширять функциональность. Выделим основные проблемы неструктурированного кода:
- отсутствие общей для проекта структуры кода
- низкая связность кода (low cohesion) - бизнес-логика "размазана" по разным участкам кода в проекте
- высокая связанность кода (tight coupling) - модули кода могут выполнять действия только в связке с другими модулями или внешними данными)
Соответственно, и решение этих проблем лежит в:
- архитектуре - применении паттерна MVC
- повышении связности кода (high cohesion) - организации модулей, каждый из которых реализует одну, заранее хорошо определенную бизнес-функцию
- понижении связанности кода (loose coupling) - делать модули как можно менее зависимыми друг от друга, передавая параметры или обмениваясь сообщениями
Хороший фреймворк призван решить эти три проблемы. Будучи написан опытными людьми, фреймворк предложит решения и направит разработчика по правильному пути. При этом фреймворк должен без изменения подходить вашему проекту, а его код быть легким и оптимизированным. Выбирая фреймворк из нескольких, обратите внимание насколько он хорошо поддерживается, есть-ли у него сторонники, насколько хороша документация.
Опишу несколько популярных фреймворков. Как правило, фреймворки используют такой паттерн для URL:
index.cfm?action=module.procedure
Единая точка входа в приложение - index.cfm, и некоторый "переключатель" - переменная action, в которой задается модуль и действие внутри этого модуля.
Fusebox
Один из ранних фреймворков. В версии 3 использовал CFML для описания модулей, в версии 4 это нужно делать через XML. В 5 версии появилась возможность отказаться от XML в пользу использования CFC. В настоящий момент фреймворк не поддерживается, хотя core-файлы стабильны и пригодны для работы с любым проектом.
Mach-II
Первый объектно-ориентированный фреймворк, представлен с появлением поддержки CFC в Coldfusion MX (2003). С помощью XML-файла фремворк описывает события (events), компоненты CFC, реагирующие на эти события, и views - CFM-файлы, отвечающие за внешний вид. Фреймворк развивается, на нем реализованы многие корпоративные приложения.
Coldspring
http://www.coldspringframework.org/
При работе с многими CFC-компонентами может встать вопрос об их упорядоченном использовании. Например, когда нужно инстанцировать зависимые объекты или синглтоны. Чтобы не следить за зависимостями вручную, фреймворк Coldspring может делать это автоматически. Для этого используется XML-конфигурация используемых объектов (beans), а для вызова конкретного объекта можно использовать лишь запрос к фабрике объектов Coldspring.
TransferORM
Object-Relation Mapping - технология работы с данными в БД с помощью объектного подхода. Один экземпляр (объект) сопоставляется (mapped) одной строке в таблице БД. Это позволяет получать доступ (считывать), добавлять, изменять и удалять записи из БД, не прибегая к написанию SQL-кода. В конечном итоге это экономит время на рутинных операциях. TransferORM - это ORM-фреймворк для Coldfusion 7 и выше. Существующие таблицы БД (и их связи) описываются XML-файлом, по которому в последствии генерируются объекты. Каждый объект содержит поля, соответствующие полям таблицы в БД, а также геттеры-сеттеры для доступа к этим полям. TransferORM поддерживает возврат списков сущностей, поиск по фильтру, поиск по запросу (используется язык TQL - Transfer Query Language).
FW/1 (Framework One)
Новый фремворк, построенный по принципу Convention over Configuration, при котором описание структуры ложится на файловую систему. Фреймворк реализован всего одним CFC файлом, от которого нужно унаследовать Application.cfc нового проекта. Фреймворк реализует паттерн MVC таким образом. Контроллером модуля является один CFC, находящийся в папке /controllers, в этом контроллере определены методы данного модуля. Для доступа к внешним данным можно использовать службу, которая также реализуется через CFC в папке /services. После выполнения метода контроллера, данные собранные в контроллере и службе, через переменную rc передаются дальше, во view, который лежит в соответсвенно папке views/module/procedure.cfm. Для облегчения дизайнерского труда используются шаблоны, которые лежат в папке /layouts и могут иметь три уровня вложенности. Вот иллюстрация, как происходит вызов и сборка конечной страницы:
Минимально необходимым файлом для создания приложения на FW/1 является /views/module/procedure.cfm. Остальные файлы, включая контроллеры, сервисы и лэйауты, необязательны. Framework One подкупает своей простотой использования и скоростью работы.
Заключение
Описанные фреймворки - не единственные, но популярные, которые я бы лично рекомендовал для любого проекта. Мой личный фаворит - FW/1 - за его легкость и простоту. Используя наработанные библиотеки классов (CFC) в проекте на базе FW/1, я обычно использую Coldspring для описания зависимостей между классами в библиотеке, а также TransferORM для упрощения рутинных операций. Для сложных запросов я не прибегаю к помощи TransferORM, чтобы не усложнять код; я пишу обычный SQL-код и хранимые процедуры. Применять тот или иной фреймворк нужно осмысленно, примеряя его возможности к потребностям конкретного проекта и конкретной команды.
Дополнительное чтение по теме:
http://www.aliaspooryorik.com/blog/index.cfm/e/posts.details/post/oo-and-fusebox-no-xml-141
http://www.adobe.com/devnet/coldfusion/articles/frameworks_intro.html
Кінець OpenCFML
Кілька місяців тому ми згадували про створення дорадчого комітету з CFML, що мав би займатися розробкою та стандартизацією мови програмування. Плани були серйозні, команда підібралась відповідна.
Але не так сталося, як гадалося. Після тривалого затишшя з’явилися повідомлення про "смерть" проекту.
Спочатку Адам Леман повідомив про те, що Adobe виходить з комітету. Незабаром відреагував і Шон Корфілд, а також і Метью Вудвард, остаточно розв’язавши ситуацію.
В чому ж причини?
В першу чергу недостаток відкритості, що не спонукало учасників до активної діяльності.
Проблематичність пошуку консенсусу, наприклад в стандартизації CFScript в новій версії ACF, призвела до занепаду зацікавлення учасників, що й вилилося в поступове згасання діяльності.
Звісно, не обійшлося від деяких взаємних звинувачень в ігноруванні прийнятих рекомендацій та інших непорозуміннях.
Альтернативою цього року стало створення відкритої спільноти Conventional CFML Wisdom в групах Google, в якій спілкуються в тому числі деякі (колишні й поточні, якщо ще можна так сказати) учасники комітету.
Гадаю, що ця подія не справить великого впливу на спільноту, бо комітет так і не досяг жодних цілей, проваливши затвердження стандарту CFML2009. Але в цілому ситуація малоприємна, хоч і корисна з точки зору досвіду організації роботи зі стандартизації мови CFML, що все одно доведеться колись робити.
Новий сайт з CFML документації: CFMLDocs
Дейл Фрейзер розповів про те, чому він вирішив створити альтернативу стандартній документації, а також про заплановані можливості проекту.
Про все це в його публікації New ColdFusion Documentation Site Launched
Серед вже реалізованих варто відмітити простий, але зручний AIR-клієнт.
Сам проект: http://cfmldocs.com
Корисні посилання від Чарлі Арехарта
Чарлі продовжує свою місію систематизації ресурсів CF-світу.
Цього разу він уклав два вагомі списки посилань за наступними темами:
- Ultimate list of CF debugging output template alternatives
- The Ultimate Var Scope Resource list? Understanding/resolving problems with the var scope in CFML
В першій публікації розповідається про те, які є способи заміни стандартних шаблонів для налагодження ColdFusion. Треба зауважити, що тут не розкрито тему для Railo, котрий має ще більш гнучку систему шаблонів та надає більше варіантів у стандартній комплектації.
Друга розкриває суть та різні аспекти проблеми з VAR-scope, зокрема й про особливості його в CF9. Must read для кожного CFML-програміста.
Спільнота для тих, хто працює з CFML
Приблизно так, як звучить заголовок, можна перекласти повну назву сайту, що тільки набирає обертів. Проект являє собою простеньку реалізацію професійної соціальної мережі (такий собі вузькоспеціалізований linked.in), в якій можливості "соціалізації" додані здебільшого задля розваги.
Детальніше про все це можна дізнатися на самому сайті: Working With CFML
І на додаток, гарненькі тематичні шпалери: ColdFusion Wallpaper - Revolution
Про CFML Advisory Commitee
Текст нижче є вільним переказом публікації Getting to Know the CFML Advisory Committee з HOF. В ній розповідається (оповідач Роб Брукс-Білсон) про те, що собою являє дорадчий комітет (Advisory Commitee) з CFML, хто є його учасниками та які задачі він розв'язує.
Комітет було створено з ініціативи Adobe для вирішення двох завдань: стандартизація мови CFML між виробниками двигунів, а також розробка шляху розвитку мови. Окремий наголос робиться на тому, що група фокусується не на платформі ACF, а саме на мові програмування, звідти й назва.
На даний момент до комітету входять: Бен Форта і Адам Леман (Adobe), Шон Корфілд (Railo), Мет Вудвард (Open BD), а також Реймонд Кемден, Пітер Джей Феррел та сам Роб Брукс-Білсон (представники спільноти).
Головною метою було визначено проведення класифікації мови за трьома базовими категоріями для основних виробників:
- Базові. Базові можливості CFML мають бути втілені всіма виробниками однаково та забезпечувати сумісність (переносимість) для коду.
- Додаткові. Не обов'язкові до втілення можливості CFML, але у випадку прийняття до розробки мусять так само бути сумісними.
- Специфічні. Будь-які додаткові можливості мови, що можуть підтримуватися тільки одним виробником, або працювати по-різному, навіть якщо втілені декількома. Сумісність не вимагається.
З липня 2008 року комітет почав обговорювати кожну мітку та функцію з попереднього набору та визначати приналежність їх до одної з категорій голосуванням. В січні 2009 року цю роботу було завершено та опубліковано результати.
Відразу після цього розпочалася робота зі встановлення стандарту мови CFML2009, чимало з якого вплинуло на синтаксис нових можливостей ColdFusion 9, зокрема вже згадувані зміни в CFScript.
Треба зауважити, що далеко не всі пропозиції комітету було враховано, зокрема через нестачу часу (вихід бети відбувся у самий розпал роботи комітету), тому певні відмінності в ACF9 залишилися й у релізі.
На даний момент позиція комітету полягає в тому, щоби решта виробників внесли аналогічні до Adobe зміни та привести стандарт до фактичної ситуації. З великою ймовірністю можна стверджувати, що так і буде.
Відтепер планується оновлювати стандарт мови кожні два роки, і вже розпочалася робота над наступним CFML2011. Цього разу комітет планує бути на гребні хвилі розробки, щоб забезпечувати кращі можливості співпраці для всіх виробників.
Актуальну інформацію щодо роботи комітету, а також опис стандарту мови можна відшукати на сайті OpenCFML.org
Покращуючи CFScript
Шон Корфілд розповів про те, як відбувається еволюція CFScript. Він навів приклад того, як було втілено функції в різних серверах застосунків та роль CFML Advisory Commitee. Ми вже колись згадували про цю тему.
Що цікаво, я вже довгий час сповідую синтаксис, аналогічний до наведеного прикладу ColdBox: класичне визначення cffunction+cfargument, а тіло на cfscript.
Треба відмітити, що до широкого використання нового синтаксису ще далеченько, аж поки CF9 та Railo не займуть достатньо велику частину ринку. До того часу доведеться писати сумісний з CF8 код, щоб забезпечити собі спокійний тил.
CFML 101 - Помилки новачків (друга частина) та веселощі зі списками
Ерік Кобб продовжує (див. про першу частину) серію публікацій про основи CFML.
В другій публікації про помилки новачків він розповідає про особливості використання Application.cfm (рекомендується уважно переглянути коментарі, бо в цій частині є певні помилки), деякі можливості вкладання викликів функцій та необхідність використання cfparam.
В публікації Fun with Lists розповідається про переваги використання списків, котрі є вельми зручним та ефективним з точки зору швидкодії інструментмо.
Дискусія: чому CFML, а не Java?
Нещодавно Шон Корфілд (Sean Corfield) опублікував невеличку замітку, в якій критично висловився щодо компанії, котра витратила три роки (!) на переписування сайту з CFML на Java.
Обговорення тої самої новини на TechCrunch вилилося в значну дискусію за участі великої кількості авторитетних членів спільноти (навіть Бен Форта завітав!), частина якої перекинулася й на коментарі до посту Шона.
Зокрема, в них відмітився оборонець ідеї переписування (можливо, учасник) Девід Теннерсін (David Tannersyn), котрий викликав нову хвилю обговорення, що призвело до написання Шоном нової ґрунтовної публікації Why CFML? Why not Java?, котра має на меті розставити крапки над "і" в цій дискусії.
Рекомендую до ознайомлення, все доволі цікаво.
CFML 101 - Помилки новачків, частина 1
Ерік Кобб розпочав вельми корисну серію публікацій про типові помилки новачків в CFML, популярні питання та інші корисні речі.
Досвідчені розробники навряд чи знайдуть щось нове для себе, але для початківців дуже рекомендується до ознайомлення:
CFML 101 - Rookie Mistakes Part 1
В першій частині розповідається по символи фунтів (pounds, #), грамотне використання cfoutput, доцільність вказування області видимості змінних та небезпеки використання Evaluate.
Я проходив свого часу через усі вказані пункти, але завдяки ознайомленню з існуючими зразками гарного коду швидко позбувся цих звичок :)
На додаток, варто відмітити й знайдений читачами виняток з описаних правил, зокрема про доцільне використання Evaluate.
Запущено RailoAjax.org
Сьогодні сталася ще одна добра подія для спільноти.
Андреа Камполоньї (Andrea Campolonghi) повідомив у гугл-групі Railo про те, що вийшов на інтернет-орбіту RailoAjax.org. Як помітно з назви, проект призначено для втілення cfajaxproxy, cfdiv and та інших RIA-фішок.
За клієнтську взаємодію відповідає jQuery, за серверну, вочевидь, CFML.
Варто додати, що проєкт має вікі та трекер на базі Trac: docs.railoajax.org
Про деякі особливості Application.cfc
Не всі розробники задумуються над тим, що Application.cfc це не тільки Application, але й повноцінна CFC. Використання її саме у якості компоненти дає кілька цікавих можливостей.
Наприклад, розглянемо таку просту компоненту:
<cfcomponent output="false">
<cfset this.name = "application_introspect" />
<cfset this.foo = "bar" />
<cffunction name="onRequestStart" returnType="boolean" output="false">
<cfargument name="thePage" type="string" required="true">
<cfset application.thePage = arguments.thePage />
<cfreturn true />
</cffunction>
</cfcomponent>
А тепер спробуємо використати її.
<cfdump var="#Application#" >
<p> </p>
<cfset test = CreateObject("component", "Application") />
<!--- CF9 way
<cfset test= new Application() />
--->
<cfdump var="#test#">
<cfset test.onRequestStart("introspect.cfm") />
<p> </p>
<cfdump var="#Application#">
Таким нехитрим способом можна робити дві речі:
-
Подивитися що всередині об'єкту Application (на прикладі this.foo).
-
Зручно маніпулювати Application scope.
Результат роботи вищевказаного коду виглядатиме так:
Groups: OOP in ColdFusion
Нещодавно було створено Google групу для обговорення особливостей та доцільності взагалі (це окрема гаряча тема) об'єктно орієнтованого програмування в CFML.
Там вже встигли відмітитися чимало відомих членів спільноти.
Що характерно для цієї теми, більше половини обговорень присвячено теоретичним питанням.
Офіційна документація з ColdFusion 9 CFML
Поки не доступна з публічних сторінок підтримки.
За традицією, з дещо переробленим дизайном. З можливістю експорту в PDF.
Adobe ColdFusion 9 CFML Reference
Сайт №1 для CF-розробника.
Реалізація cfdump в інших мовах
Не секрет, що CF-програмісти обожнюють cfdump за його зручність та інформативність. Деякі люблять його настільки, що власноруч створюють клони теґу для інших мов. Зрештою, навіть я колись робив це на PHP, як модуль внутрішньої CMS компанії.
Тож варто поглянути на наступні реалізації:
- dBug для PHP від Kwaku Otchere;
- prettyPrint для JavaScript від James Padolsey.
Обидва виглядають доволі симпатично, хоча й не зрівняються з величчю CFML :)
Пропоновані зміни у визначенні функцій в CFScript
Нещодавно Шон Корфілд (Sean Corfield) опублікував замітку з циклу CFML Advisory, що пропонує ряд змін в синтаксисі в наступних версіях CFML (що стосуватиметься всіх серверів, що найприємніше).
Зокрема, при визначенні функції можна буде вказувати:
- access (public, private, package, remote)
- return type
- argument types
- default values
Наприклад, ось так:
public string function greet(string name, string greeting = "Hello") {
return greeting & " " & name;
}
Деякі речі можуть бути опущені:
function greet(name, greeting = "Hello") {
return greeting & " " & name;
}
Що аналогічне цьому:
public any function greet(any name, any greeting = "Hello") {
return greeting & " " & name;
}
Ну і обов'язкові агрументи, куди ж без них:
public string function greet(required string name, string greeting = "Hello") {
return greeting & " " & name;
}
Хтось резонно може зауважити, що це є черговий крок в сторону Java.
Ну й добре, аби було на користь розробникам, особливо любителям CFScript.
RSS