Анонс. Предварительные правила и особенности именования пакетов
5 views
Skip to first unread message
Maxim Miroshnichenko
May 14, 2011, 12:03:02 PM5/14/11
to wp-pa...@googlegroups.com
Пакетов много, очень много, и будет еще больше, и чтобы разработчикам можно было ориентироваться по имени пакета "что он делает", то выношу на обсуждения предварительную редакцию правил именования пакетов.
====================
* Если пакет называется xxxAPI, то это означает, что пакет предоставляет только программное API без какой-либо подсистемы рендеринга страниц. Как правило, такой пакет будет реализован как singleton-инкапсулятор, то есть доступ ко всем метода будет доступен примерно так: xxxAPI::Get()->метод().
Иными словами, это чистое API: сервисы, x-классы, системные классы, логика.
* Если пакет является расширением к Engine, то он будет называться EngineXxx (начинаться на Engine). Яркий пример таких пакетов: EngineDebug, EngineAJAX, EngineTextPages, …
В случае, если в имени пакета нет явного намека на Engine, пакет без вызова MyPackageName::Initialize() не может подключать автоматически какие-либо Eventы/Listenerы в Engine.
* Если имя пакет заканчивается на Service, то это как правило устаревший пакет, пакеты с таким именем не создаются и не поддерживаются после 2011-05.
(Нюанс в том, что само слово Service - это только как правило только бизнес-логика, причем заточенная исключительно под паттерн фабрика сервисов)
* Если в имени пакета встречается "JS" - то это в первую очередь указывает на то, что пакет JavaScriptовый. В большей степени такие пакеты будут начинаться на JS. Например, JSPrototype, JSPrototypeCalendar и т.д. Но если в имени пакета уже есть JS (например, DateJS), то в начало мы дописывать JS не будем.
Также, есть исключения, в частности, для jQuery - пакет так и называется - jQuery.
* По названию пакетов не сложно догадаться, что есть пакеты-расширения. Например, EngineAJAX, EngineDebug - сильно зависят от Engine и расширяют его. JSPrototypeCalendar - зависим от фундамента JSPrototype. И т.д.
--
С уважением,
Максим Мирошниченко,
студия WebProduction.
www: http://webproduction.com.ua/
email: m...@webproduction.com.ua
office: off...@webproduction.com.ua
tel. 1: +38 (050) 447-95-30
tel. 2: +38 (0462) 61-42-61
====================
* Если пакет называется xxxAPI, то это означает, что пакет предоставляет только программное API без какой-либо подсистемы рендеринга страниц. Как правило, такой пакет будет реализован как singleton-инкапсулятор, то есть доступ ко всем метода будет доступен примерно так: xxxAPI::Get()->метод().
Иными словами, это чистое API: сервисы, x-классы, системные классы, логика.
* Если пакет является расширением к Engine, то он будет называться EngineXxx (начинаться на Engine). Яркий пример таких пакетов: EngineDebug, EngineAJAX, EngineTextPages, …
В случае, если в имени пакета нет явного намека на Engine, пакет без вызова MyPackageName::Initialize() не может подключать автоматически какие-либо Eventы/Listenerы в Engine.
* Если имя пакет заканчивается на Service, то это как правило устаревший пакет, пакеты с таким именем не создаются и не поддерживаются после 2011-05.
(Нюанс в том, что само слово Service - это только как правило только бизнес-логика, причем заточенная исключительно под паттерн фабрика сервисов)
* Если в имени пакета встречается "JS" - то это в первую очередь указывает на то, что пакет JavaScriptовый. В большей степени такие пакеты будут начинаться на JS. Например, JSPrototype, JSPrototypeCalendar и т.д. Но если в имени пакета уже есть JS (например, DateJS), то в начало мы дописывать JS не будем.
Также, есть исключения, в частности, для jQuery - пакет так и называется - jQuery.
* По названию пакетов не сложно догадаться, что есть пакеты-расширения. Например, EngineAJAX, EngineDebug - сильно зависят от Engine и расширяют его. JSPrototypeCalendar - зависим от фундамента JSPrototype. И т.д.
--
С уважением,
Максим Мирошниченко,
студия WebProduction.
www: http://webproduction.com.ua/
email: m...@webproduction.com.ua
office: off...@webproduction.com.ua
tel. 1: +38 (050) 447-95-30
tel. 2: +38 (0462) 61-42-61
Maxim Miroshnichenko
May 21, 2011, 12:59:25 PM5/21/11
to wp-pa...@googlegroups.com
Предварительные правила и особенности именования пакетов
Дата создания: 2011-05-01.
Автор: Maxim Miroshnichenko <m...@webproduction.com.ua>
Статус документа: в разработке
Ориентировочная дата полного внедрения: 2011-09-01.
==============================
API-пакеты
==============================
Если пакет называется xxxAPI, то это означает, что пакет предоставляет только программное API без какой-либо подсистемы рендеринга страниц. Как правило, такой пакет будет реализован как по паттерну Singleton (одиночка), то есть доступ ко всем методам пакета будет доступен примерно так: xxxAPI::Get()->method(…).
Иными словами, такие пакеты - это чистое API: сервисы, x-классы, системные классы, логика. Но никак не отображение.
==============================
Пакеты-расширения
==============================
По названию пакетов не сложно догадаться, что есть пакеты-расширения. Например, EngineAJAX, EngineDebug - сильно зависят от Engine и прямиком расширяют его.
Яркие примеры пакетов-расширений: EngineBlog, EngineStore, EngineTextPages, …
Но не стоит путать пакеты-расширения и пакеты, основанные на фундаменте другого пакета.
Например, JSScriptAculoUs основан на JSPrototype, но в названии нет "JSPrototype".
Также, существуют пакеты, у которых в самом названии уже есть названия других пакетов.
Например, JSPrototypeCalendar - он так и называется в оригинале, его так назвал автор.
==============================
Engine-пакеты
(частный случай пакетов-расширений)
==============================
==============================
Service-пакеты (устаревшие)
==============================
Если имя пакет заканчивается на Service, то это как правило устаревший пакет, пакеты с таким именем не создаются и не поддерживаются после 2011.05 (May, 2011).
(Нюанс в том, что само слово Service - это только как правило только бизнес-логика, причем заточенная исключительно под паттерн фабрика сервизов).
==============================
Utils-пакеты
=============================
Utils-пакеты - пакеты, которые помогают организовать что-либо на основе своего паттерна.
Например, FactoryUtils - помогают организовать фабрику объектов (в частности, фабрику сервисов).
==============================
JS-пакеты
==============================
Если в имени пакета встречается "JS" - то это в первую очередь указывает на то, что пакет JavaScript-овый. В большей степени такие пакеты будут начинаться на JS. Например, JSPrototype, JSPrototypeCalendar и т.д. Но если в имени пакета уже есть JS (например, DateJS), то в начало мы дописывать JS не будем.
Также, есть исключения, в частности, для jQuery - пакет так и называется - jQuery.
==============================
CSS-пакеты
==============================
Аналогично JS-пакетам: если в имени пакетов встречается "CSS" - то пакет скорее всего будет содержать средства по работе с CSS.
Например, при подключении CSSReset - подключается стиль cssreset.css,
CSSLess - добавляет поддержку less в PackageLoader, в следствии чего для всего CSS в проекте можно применять less-синтаксис.
==============================
UI-пакеты
==============================
UI-пакеты начинаются на "UI" - от User Interface. Это пакеты, которые подключаются к Engine и PackageLoader, чтобы внести в проект некие UI-элементы. Например, при подключении пакета UIWPP в вашем проекте в Engine сразу будут необходимые tpl-global, tpl-404, css-стили .wpp-menu, .wpp-footer, .wpp-header, .wpp-h1, .wpp-h2, .wpp-content, .wpp-button и т.д. Более подробно про предоставляемые возможности описывает сама документация по пакету.
Концепция UI-пакетов только разрабатывается, большая часть пакетов проприетарна (разрабатывается под клиента и его проекты).
Тем не менее, в #wpp есть понятие UI-пакеты, используя правила именования стилей в UI-пакетах теоретически можно мгновенно менять интерфейс любого проекта.
Особенность: выше описанные UI-пакеты именно начинаются на "UI".
Если вы разрабатываете UI-пакет для какого-либо проекта, назовите его именно UIxxx.
Не стоит путать "свои" UI-пакеты с такими пакетами как jQueryUI, JSPrototypeUI, которые являются расширением к jQuery/Prototype, и в тоже время так и называются в авторском оригинале.
Дата создания: 2011-05-01.
Автор: Maxim Miroshnichenko <m...@webproduction.com.ua>
Статус документа: в разработке
Ориентировочная дата полного внедрения: 2011-09-01.
==============================
API-пакеты
==============================
Если пакет называется xxxAPI, то это означает, что пакет предоставляет только программное API без какой-либо подсистемы рендеринга страниц. Как правило, такой пакет будет реализован как по паттерну Singleton (одиночка), то есть доступ ко всем методам пакета будет доступен примерно так: xxxAPI::Get()->method(…).
Иными словами, такие пакеты - это чистое API: сервисы, x-классы, системные классы, логика. Но никак не отображение.
==============================
Пакеты-расширения
==============================
По названию пакетов не сложно догадаться, что есть пакеты-расширения. Например, EngineAJAX, EngineDebug - сильно зависят от Engine и прямиком расширяют его.
Яркие примеры пакетов-расширений: EngineBlog, EngineStore, EngineTextPages, …
Но не стоит путать пакеты-расширения и пакеты, основанные на фундаменте другого пакета.
Например, JSScriptAculoUs основан на JSPrototype, но в названии нет "JSPrototype".
Также, существуют пакеты, у которых в самом названии уже есть названия других пакетов.
Например, JSPrototypeCalendar - он так и называется в оригинале, его так назвал автор.
==============================
Engine-пакеты
(частный случай пакетов-расширений)
==============================
Если пакет является расширением к Engine, то он будет называться EngineXxx (начинаться на Engine). Яркий пример таких пакетов: EngineDebug, EngineAJAX, EngineTextPages, …
В случае, если в имени пакета нет явного намека на Engine, пакет без вызова MyPackageName::Initialize() не может подключать Engine автоматически какие-либо Eventы/Listener'ы.
==============================
Service-пакеты (устаревшие)
==============================
Если имя пакет заканчивается на Service, то это как правило устаревший пакет, пакеты с таким именем не создаются и не поддерживаются после 2011.05 (May, 2011).
(Нюанс в том, что само слово Service - это только как правило только бизнес-логика, причем заточенная исключительно под паттерн фабрика сервизов).
==============================
Utils-пакеты
=============================
Utils-пакеты - пакеты, которые помогают организовать что-либо на основе своего паттерна.
Например, FactoryUtils - помогают организовать фабрику объектов (в частности, фабрику сервисов).
==============================
JS-пакеты
==============================
Если в имени пакета встречается "JS" - то это в первую очередь указывает на то, что пакет JavaScript-овый. В большей степени такие пакеты будут начинаться на JS. Например, JSPrototype, JSPrototypeCalendar и т.д. Но если в имени пакета уже есть JS (например, DateJS), то в начало мы дописывать JS не будем.
Также, есть исключения, в частности, для jQuery - пакет так и называется - jQuery.
CSS-пакеты
==============================
Аналогично JS-пакетам: если в имени пакетов встречается "CSS" - то пакет скорее всего будет содержать средства по работе с CSS.
Например, при подключении CSSReset - подключается стиль cssreset.css,
CSSLess - добавляет поддержку less в PackageLoader, в следствии чего для всего CSS в проекте можно применять less-синтаксис.
==============================
UI-пакеты
==============================
UI-пакеты начинаются на "UI" - от User Interface. Это пакеты, которые подключаются к Engine и PackageLoader, чтобы внести в проект некие UI-элементы. Например, при подключении пакета UIWPP в вашем проекте в Engine сразу будут необходимые tpl-global, tpl-404, css-стили .wpp-menu, .wpp-footer, .wpp-header, .wpp-h1, .wpp-h2, .wpp-content, .wpp-button и т.д. Более подробно про предоставляемые возможности описывает сама документация по пакету.
Концепция UI-пакетов только разрабатывается, большая часть пакетов проприетарна (разрабатывается под клиента и его проекты).
Тем не менее, в #wpp есть понятие UI-пакеты, используя правила именования стилей в UI-пакетах теоретически можно мгновенно менять интерфейс любого проекта.
Особенность: выше описанные UI-пакеты именно начинаются на "UI".
Если вы разрабатываете UI-пакет для какого-либо проекта, назовите его именно UIxxx.
Не стоит путать "свои" UI-пакеты с такими пакетами как jQueryUI, JSPrototypeUI, которые являются расширением к jQuery/Prototype, и в тоже время так и называются в авторском оригинале.
Maxim Miroshnichenko
May 22, 2011, 5:20:46 PM5/22/11
to wp-pa...@googlegroups.com
Предварительные правила доступны по ссылке
http://packages.webproduction.com.ua/package/PackageLoader/article/global-wpp-sr-packages.txt/
http://packages.webproduction.com.ua/package/PackageLoader/article/global-wpp-sr-packages.txt/
Сегодня в правила добавлены описания Processor-пакетов:
==============================
Processor-пакеты
==============================
В #wpp есть определенный тип пакетов, это так называемые процессоры.
Как правило, они построены по схеме batch processors.
В терминах ООП это смесь паттернов Facade и Action.
Яркими примерами таких пакетов являются ImageProcessor и TextProcessor.
Разрабочик сам определяет последовательность обработки изображений и текстов
при помощи Action'ов вышеперечисленных пакетов.
--
With best regards,
Maxim Miroshnichenko,
WebProduction, co-founder & technical director
http://webproduction.com.ua/
m...@webproduction.com.ua
Office:
off...@webproduction.com.ua
+38 (050) 447-95-30
+38 (0462) 61-42-61
Reply all
Reply to author
Forward
0 new messages