Оценка концепции пакета JavaScript - PullRequest
Новая
       21

Оценка концепции пакета JavaScript

0 голосов
/ 17 июня 2011

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

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

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

WebAppName.category.pageName.method = function() { ... }

... или что-то подобное. Так, например, если я создаю служебную функцию для страницы администрирования веб-приложения под названием «JSMapper», она будет выглядеть так:

JSMapper.util.administration.someMethod = function() { ... }

Использование этого позволяет структурировать вещи, но после добавления десятков и десятков методов файл JavaScript может стать смехотворно длинным, даже если он разбит на разные файлы для разных страниц (например, Administration.js будет содержать все функции JSMapper.xxx.administration или что-то).

Итак, я создал PHP-скрипт, который позволяет мне разделять каждый метод JavaScript в отдельный файл и использовать структуру каталогов, чтобы регулировать, как все определяется. Итак, по сути, я могу взять эту структуру каталогов: 

JSMapper
|-index.php
|-scripts
| |-JSMapper
| | |-repository
| | | |-administration
| | | | |-someRepositoryMethod.js
| | |-util
| | | |-administration
| | | | |-someMethod.js
| | | | |-someOtherMethod.js
| | | |-aGeneralUtilityMethod.js
|-treescript
| |-treescript.php

... и включите файл treescript.php с параметром в тег <script>:

<script type='text/javascript' src='treescript/treescript.php?package=JSMapper'></script>

PHP-скрипт выходит и получает все файлы, определяет пространства имен на основе структуры каталогов и дает мне содержимое всех запрошенных файлов: 

if(typeof window.JSMapper == "undefined") JSMapper = {};
if(typeof JSMapper.util == "undefined") JSMapper.util = {};

if(typeof JSMapper.util.administration == "undefined") JSMapper.util.administration = {};

JSMapper.util.admin.someMethod = function() {
    // do something
};

JSMapper.util.admin.someOtherMethod = function() {
    // do something else
};

JSMapper.util.aGeneralUtilityMethod = function() {
    // this method is not specific to the administration page
};

if(typeof JSMapper.repository == "undefined") JSMapper.repository = {};

if(typeof JSMapper.repository.administration == "undefined") JSMapper.repository.administration = {};

JSMapper.repository.admin.someRepositoryMethod = function() {
    // do something
};

Он также может принимать подпакет в качестве аргумента, например JSMapper.util, и он будет извлекать только методы из этого подпакета.

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

Так что мой вопрос таков: это практический подход? Это подходит для веб-разработки корпоративного уровня? Какие недостатки я пропускаю? Любые мысли, комментарии, альтернативные решения приветствуются. Я могу предоставить файл сценария PHP по запросу. Спасибо.

1 Ответ

0 голосов
/ 17 июня 2011

Общая идея вполне обоснована, но, вероятно, неправильная реализация собственной библиотеки и схемы упаковки. Вы смотрели на RequireJS ? Он реализует спецификацию CommonJS AMD. По крайней мере, взгляните на соответствующие спецификации CommonJS: Модули и Пакеты .

...