Не пора ли объединить знания, привести в некую структуру? Давно уже сидим на скриптах и каждый раз при создании компонента пишем заново с нуля. Где прогресс? 
Винградовский форум о скриптах - один из центральных форумов рунета по данной тематике. Поэтому мы можем навязывать наши осмысленные и утвержденные решения, так как они оптимальны и специалистов здесь хватает. Я считаю обязательным создание именно нашего фреймворка и обязательной к нему документацией. После полноценной разработки данного проекта ответы на вопросы в большинстве случаях будут ссылки на конкретную часть нашей документации, описанной в научно-популярном стиле. А ведь не за горами написание книги с использованием этих материалов. Сейчас некоторые авторы книг, такие как Закас, Мак-Пик, Фосетт и другие пропагандируют свои библиотеки. Созданием единой документации можно таким образом снять загрузку с форума и заставить людей читать. Говоря о форуме, то мне кажется, что здесь не хватает логического разделения ответа на вопрос: на сами обсуждения и на так называемое оптимальное решение конкретной проблемы.
   Мои мысли по поводу фреймворка: разумеется библиотека должна состоять из модулей. Понятное дело, что вес должен быть минимальным. Я не хочу рассуждать  об абстракциях и слышать их. Все конкретно, приземленно.

   Мое решение:
 библиотека пишется в соответствии определенной спецификации. 

библиотека имеет в себе "системные переменные". например, $version, $platform, $units[](массив). и "системные функции". например, $include(). а также из функций и объектов, которые подключаются из модулей.

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

библиотека кроссбраузерна. каждый модуль рассчитан под конкретный тип браузера (ie, opera, firefox + mozilla, safari)
клиент будет загружать только те части модулей, которые нужны под его браузеру. это можно решить компиляцией модуля. как это понимать? 
разработчик пишет, не думая о размере кода, скрипт. затем проверяет все ли пашет. после этого запускает специальный мною написанный компилятор - программу, отвечающую за поиск использованных функций в модулях,  - и создает например единый код.

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

а теперь представьте. вопросы на форуме по кроссбраузерности и размера вообще бы отпали=)

ребята, делимся мыслями

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

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

JSman, 

вспомнилось мне, что чуть меньше года назад ты горел другой идеей. Сгорел? ;-)


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


Какой спецификации?


"The dollar sign is intended for use only in mechanically generated code." (ECMAScript 7.6)


Не могу представить.

какая у тебя память хорошая! =) мне на самом деле приятно, что кто-то помнит) 

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

знаешь, эта тема сильно связана с той.. слова на ветер не летят. ;-)



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



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


ну посмотрим, если доживем.

=============================================================================================
=============================================================================================

введение кончилось. разговоры в сторону. определяемся с правилами написания функций, переменных. 

=======ШАБЛОН================================================================================

имена системных функций и переменных - ^\$([a-z][A-Z]*)+


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

=============================================================================================
СВОИ ПРИМЕРЫ ИМЕНОВАНИЯ ДАВАТЬ В СООТВЕТСТВИИ С ШАБЛОНОМ, УКАЗАННОМ ВЫШЕ, ТО ЕСТЬ С ИСПОЛЬЗОВАНИЕМ РЕГУЛЯРНЫХ ВЫРАЖЕНИЙ.



Это сообщение отредактировал(а) JSman - 2.9.2007, 20:04

 прогресс в головах программистов.

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

разберутся кому что надо и скопипастят....

dstorm81, обрати внимание на это

сорри, я не спец в регвыр, но не проще было написать так: ^\$[A-Za-z]+?
или сказать, что имена начинаются с $ и состоят из латинских символов?
и вообще - разве это главное?

Слегка разные вещи. JSman требует не только доллар на первом месте, но и букву в диапазоне [a-z] на втором, то есть букву в соответствующем регистре.

ВНИМАНИЕ! перед критикой прошу вас прочитать вдумчиво от начала до конца.


ПЕРЕЧЕНЬ ЗАКРЫТЫХ СИСТЕМНЫХ ПЕРЕМЕННЫХ И ФУНКЦИЙ.
 
в конечном коде класса они НЕ используются. они предназначены для компилятора сценариев.

$name /:String:/ - название браузера 

================================================================================

ПЕРЕЧЕНЬ ОТКРЫТЫХ СИСТЕМНЫХ ПЕРЕМЕННЫХ И ФУНКЦИЙ


$version /*:Number*/ - версия браузера

$classFolder /*:String*/ -директория с классами
ВНИМАНИЕ! переменная используется только в рамках функции $include.

$classes /*:Object*/ - ассоциативный массив, состоящий из имен загруженных модулей
ВНИМАНИЕ! переменная используется только в рамках функции $include.

function $createClass(className /*:String*/)/*:null*/ - создает JavaScript Object с именем аргумента функции 
ВНИМАНИЕ! эта функция используется только один раз в каждом файле класса в секции "2. автоматическое создание класса". См. Структура файла класса

function $include (importClassName /*:String*/)/*:Boolean*/ - загружает класс (объект) с именем importClassName, добавляет его в коллекцию $classes и возвращает успешность загрузки. функция общается к файлу importClassName.js в директории $classFolder

пример использования:

    $include('System.Manifest');
    
    System.Manifest.load(themePath);

обратите внимание, что загрузка класса System.Manifest - не означает загрузку класса System! этот прием используется только для логической группировки классов.
================================================================================

ПРАВИЛА СОЗДАНИЯ КЛАССОВ
-------------------------------------------------------
Структура файла класса

Состоит из двух частей:
1. конструктор класса. именование конструктора: РодительскийОбъект_ДочернийОбъект. 
пример

    function System_Manifest() {
    var _ = this; 
    ...
    }

обязательно создайте указатель _ на текущий объект.
для описания методов используется сначало объявление функции, а только потом ее присваивание к свойству класса.

пример

    function System_Manifest() {
    var _ = this; 
        function load(themePath /*:String*/) { ... }
        _.load = load;
    ...
    }


2. автоматическое создание класса

    $createClass('System.Manifest');
    System.Manifest = new System_Manifest();
-------------------------------------------------------
Именование методов класса

Методы делятся на 2 вида:
1. Общие для всех браузеров - функции поддерживаются всеми браузерами. 
пример

    function System_Manifest() {
    var _ = this; 
        function load(themePath /*:String*/) { ... }
        _.load = load;
    ...
    }

2. Специфические.
Так как клиент будет загружать, только тот код, который ему предназначается в зависимости от браузера, то нужно определить специфические методы.
Правило именования: $name_methodName

затем все специфические методы для достижения кроссбраузерности библиотеки объединяются одним общим методом.

пример

    function System_Manifest() {
    var _ = this; 
    
        function $opera_load(themePath /*:String*/) { ... }
        function $firefox_load(themePath /*:String*/) { ... }
        function $internetExplorer_load(themePath /*:String*/) { ... }
        ...
        
        _.$opera_load = $opera_load;
        _.$firefox_load = $firefox_load;
        _.$internetExplorer.load = $internetExplorer_load;
        ...          
    
        function load(themePath /*:String*/) { 
        eval('_.'+ $name + '_load(' + themePath +');');        
         }
        _.load = load;
    ...
    }

данный код является кроссбраузерным, что облегчает проверку в любом браузере.
================================================================================

О КОМПИЛЯТОРЕ
-------------------------------------------------------
Итак, мы имеем ограниченное число браузеров, которым хотим обеспечить поддержку. Идея в следующем.
Файл с кодом каждого класса после применения компилятора делится на столько частей, сколько браузеров поддерживается. В каждой части содержится только специфический для определенного браузера код. Вытягивание кусков кода идет в соответствии c именованием методов класса ($name_method). Таким образом, в конечной части процесса компиляции будут полностью отсутствовать методы второго типа (спицифические) с точки зрения синтаксиса, вместо имени специфического будет использоваться общий метод. Более того, компилятор обеспечит удаление тех методов, которые не нужны при решении конкретной задачи.

пример

содержимое файла разработчика 

    $include('System.Manifest');
    
    System.Manifest.load(themePath);
    
начальное содержимое файла System.Manifest.js
    function System_Manifest() {
    var _ = this; 
    
        function $opera_load(themePath /*:String*/) { ... }
        function $firefox_load(themePath /*:String*/) { ... }
        function $internetExplorer_load(themePath /*:String*/) { ... }
        ...
        
        _.$opera_load = $opera_load;
        _.$firefox_load = $firefox_load;
        _.$internetExplorer.load = $internetExplorer_load;
        ...          
    
        function load(themePath /*:String*/) { 
        eval('_.'+ $name + '_load(' + themePath +');');        
         }
        _.load = load;
    ...
    }
    
    $createClass('System.Manifest');
    System.Manifest = new System_Manifest();

вместо этого кода после компиляции будет, например, 3 файла класса для каждого браузера с именем System.Manifest.js в папках 'opera', 'firefox', 'internetExplorer' со следующим содержимым: 

    function System_Manifest() {
    var _ = this; 
        function load(themePath /*:String*/) { ... }
        _.load = load;
    ...
    }
    
    $createClass('System.Manifest');
    System.Manifest = new System_Manifest();    
    
содержимое метода load будет разным в 3х файлах.

на этапе проверки браузера $classFolder присвоит новое значение взависимости от имени браузера.
---------------------------------------------------------------------
Компилятор также имеет возможность сжатия скриптов так называемым обфускатором.

пишите комментарии. затем приступим к реализации системных функций. кто в команде?

Так ты хочешь фреймворк винградовский создать или всё-таки освоить свой компилятор? Если первое, то начинаешь явно с конца, если второе, то отдельный код для отдельного браузера - это слегка пугает:

- как точно определить браузер/версию?
- зачем разбивать модули по-браузерно, если можно сделать один, подстроив его нужным макаром? *

(*)допустим, поддержка браузера А решается тремя строчками, удобно ли подтягивать эти три строчки отдельным скриптом...

по специфическим функциям или объектам каждого браузера. 


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

2 JSman
мда, тяжко читать такое, ох как тяжко...

вот про это поподробнее, или признайся что куришь

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

процесс компиляции скриптов аналогичен компиляции программного кода delphi, например. 

разработчик создает свой сценарий и подключает к нему классы. проверяет как страница работает в различных браузерах. затем нужно сжать код. запускает компилятор.
компилятор (программа *.exe) смотрит код разработчика и вытягивает из классов только те функции, которые использует разработчик. после выполнения каждый класс файла делится на столько частей, сколько браузеров он поддерживает. группировать скрипты под конкретные браузеры можно в папках. например js/opera, js/ie, js/ff. 





Это сообщение отредактировал(а) JSman - 4.9.2007, 11:05

ну пример приведу

ДО работы компилятора
---------------------------------------------------------------------------------
в директории на компе разработчика есть следующие файлы

< .. >
< css >
< JScriptLibrary >
         System.Manifest.js

index.html
hello.js

в hello.js он подгружает класс из папки < JScriptLibrary > с именем System.Manifest.js.

ПОСЛЕ работы компилятора 
---------------------------------------------------------------------------------
< .. >
< css >
< js >
         < opera >
                         System.Manifest.js
         < ie >
                         System.Manifest.js
         < ff >
                         System.Manifest.js
index.html
hello.js

таким образом и на серваке будет структура файлов и каталогов.

Добавлено через 2 минуты и 25 секунд
обратите внимание, что System.Manifest.js до работы компилятора весит больше, чем System.Manifest.js после. а клиент будет грузить только один из новых созданных скриптов