Модераторы: Sardar
  

Поиск:

Ответ в темуСоздание новой темы Создание опроса
> Идея:ветвь документа с определяемым представлением 
:(
    Опции темы
12345c
Дата 24.7.2006, 15:46 (ссылка)   | (голосов:1) Загрузка ... Загрузка ... Быстрая цитата Цитата


Круглый
****


Профиль
Группа: Vingrad developer
Сообщений: 2018
Регистрация: 26.12.2005
Где: наша не пропадала ?

Репутация: нет
Всего: 101



Наряду с описанием объекта - источника данных, http://forum.vingrad.ru/index.php?showtopic=105026, описываю объект - контейнер данных с определяемым (регулируемым, неопределённым) представлением. На самом деле - это ключевой объект документа, физически он может представлять собой слой Div (или объект подгрузки данных), но быть настраиваемым скриптом.

Все документы имеют структуру. По крайней мере, все, которые приятно читать :). Список содержания документа имеет структуру, списки внутри документа, страницы сайта, навигация по сайту. Пора всё это разнообразие назвать единым именем, чтобы облегчить жизнь разработчикам сайтов и документов. Как видим, каждый уровень структуры имеет 2 вида элементов: список и элемент. Список мы описываем HTML-кодом, и впоследствии в их видах тоже можем навести уровни абстракции, а сейчас займёмся вторым элементом структур - элементом списка.

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

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

Структура имеет разное представление: шапка страницы с навигацией; страница "Карта сайта"; содержание книги или документа; навигационная панель с произвольным содержанием, например, галерея рисунков или ссылок; обычный многоуровневый список; не совсем обычный, но список, скажем, сообщений, построенный на таблицах, когда часть из них могут показываться развёрнуто, часть кратко, а часть - с промежуточной развёрткой.

Везде мы видим присутствие структур и элементов, представление которых различается. Часто нам нужно взять ту же самую структуру (сайта) и изменить параметры - показывать заголовки страниц, чтобы превратить её в страницу вида "Карта сайта". Ещё изменить параметры - получить панель навигации. С этими преобразованиями предполагает справиться описываемый объект - контейнер данных с определяемым представлением.
  • Содержимое контейнера данных может быть:
  • просто часть документа, html-текст;
  • подсказка;
  • новое окно с текстом;
  • картинка с подписью (в онов окне, слое, внедряемая в поток);
  • ссылка на страницу;
  • ссылка с подсказкой;
  • ссылка на страницу в новом окне;
  • список  - следующий уровень структуры;
  • список с внедрёнными в поток подсказками;

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

Как видно из перечня возможных видов контейнера, на уровне JS объект должен вызвать разные представления html-кода, в зависимости от указания свойств элемента-контейнера. Таким образом, мы можем гибко настраивать способ отображения документов на сайте и программно управлять им (большие тексты - в новое окно, малые - в ту же страницу; есть подавление окон - выдавать в слои). Кроме того, тот же список можем использовать как панель навигации или карту сайта.

Из второго следует, что создание объекта на чистом JS возможно, но не всегда оправданно. Он будет вызываться как для малых объектов, так и для больших, как с подгрузкой данных (или за это будет отвечать DataSource.bind?), так и без, как для одних заголовков, так и для всего текста. Нужно устроить механизм чистки объекта от ненужных компонентов на уровне написания или генерации кода - механизм связывания процедур и задач. Скажем, понадобилось нам в конкретной реализации сделать из объекта только меню в шапке и вызов страниц, но не нужно выведение страниц в слои и выведение данных с разной подробностью - автоматически выбрасываем из реализации объекта неиспользуемые процедуры. Такая реализация видится на серверном языке. Кроме того, что серверный язык будет генерировать реализацию страниц с ограниченной (связанной, компилированной) версией контейнеров данных, он должен уметь генерировать статические страницы, чтобы полностью исключить себя (в случае надобности) из конечного продукта (сайта на статических страницах, документа для архивирования и просмотра как локальных файлов). Но это будет тоже отдельная тема.

Итак, js-функции объекта - контейнера данных с определяемым представлением:
  • указывать на объект данных - Div или объект подгрузки данных и уметь брать из него информацию (заголовок, начало, весь блок, автора, дату создания, список правок), работать как со связанными данными, выведенными в страницу, так и с данными, лежащими в *.js, и с объектами, умеющими подгружать данные;
  • говорить о способе представления объекта в случае клика на указатель его (не совсем пока ясно, тносится ли эта функция к списку или к объекту) - вывод в новое окно, в слой, в слой вида окна, в слой вида подсказки, как оформлять ссылки типа "Подробнее" в конце, насколько подробно показывать данные;
  • вместе со списком уметь интеллектуально располагать данные в окне или на экране - определять свой размер в зависимости от открытых слоёв или окон;

От серверного скрипта связывания _объектов_ требуется в дальнейшем не только решать, где располагать данные (на странице, в *.js или на сервере), но и что выбрасывать из функций объекта, чтобы не грузить лишнее на сайт.

Это сообщение отредактировал(а) 12345c - 24.7.2006, 15:54
PM WWW   Вверх
Sardar
Дата 24.7.2006, 17:03 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Бегун
****


Профиль
Группа: Модератор
Сообщений: 6986
Регистрация: 19.4.2002
Где: Нидерланды, Groni ngen

Репутация: нет
Всего: 317



А не черезмерная ли это абстракция?
Просто это удобно для сервера, где список опций меню и список для комбобокса (drop-down меню) это единая (XML) структура, а текущая тема и caps (capabilities, возможности пользователя,  отвечают за "низкий трафик", "есть/нет картинок", "высокий контраст" и другие индивидуальные (и никем не настраиваемые млин  smile ) опции, используемые всеми темами) создают визуальное представление. Мешать визуализацию и JS ИМХО всегда считал плохим подходом.

XForms пошли по этому же пути, элементы не задают свой внеший вид, а только смысловое действие, браузер уже представляет как лучше для конкретного пользователя (он (не)может видеть, слышать, чувствовать(доска брайля)) представить контролы. Это всё прекрасно, но ты видел реализацию XForms на JS? Это просто огромный сложный скрипт, использование которого вызывает сомнения, потому и ждём когда ИЕ наконец либо схавает плагин от Adobe либо напишет свой (мозилла уже XForms поддерживает).

И самое главное, как представить это дело? Своя собственная верстка? 


--------------------
 Опыт - сын ошибок трудных  © А. С. Пушкин
 Процесс написания своего велосипеда повышает профессиональный уровень программиста. © Opik
 Оценить мои качества можно тут.
PM   Вверх
12345c
Дата 24.7.2006, 19:06 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Круглый
****


Профиль
Группа: Vingrad developer
Сообщений: 2018
Регистрация: 26.12.2005
Где: наша не пропадала ?

Репутация: нет
Всего: 101



Не очень, потому что такие структуры везде видятся, от уровня сайта до простого списка.
Удобно и для сервера, и для представления данных вообще, т.к. данные будут в одном месте, а не разбосаны.
Эти cap-s есть вообще отдельная сруктура, её тоже хорошо бы автонастраивать, ещё одна тема для Framework-модуля. От её установок, конечно, зависит всё, не обязательно через JS. Если сайт динамический, то на PHP. В общем случае, конечно, нужно и на JS иметь возможность манипулировать видимостью элементов сайта. Если функцию возложить на Framework, думать о ней уже не надо будет.
Что значит смешивать?  JS - инструмент для автоматики сайта, а в данном случае - для генрации страниц и подстраниц.

Представлять в формате html/xhtml с дополнительными тегами выделения заголовка, аннотации и прочих технических деталей, чтобы в редакторах удобно было набирать и верстать. Скрипт смотрит на этот Div, выключает что следует и пользуется тем, о чём его поросили.

XForms не видел, но его появление напрашивается, если это тоже исходит из вопроса, что нужно пользователю от блока текста. 
PM WWW   Вверх
Sardar
Дата 24.7.2006, 19:34 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Бегун
****


Профиль
Группа: Модератор
Сообщений: 6986
Регистрация: 19.4.2002
Где: Нидерланды, Groni ngen

Репутация: нет
Всего: 317



Цитата(12345c @  24.7.2006,  18:06 Найти цитируемый пост)
JS - инструмент для автоматики сайта, а в данном случае - для генрации страниц и подстраниц.

Вот этого и боюсь. Даже сейчас когда инфу целиком грузим с сервера аяксом, как то ещё не привычно, вдруг JS заглючит или будет отключён. Потому у меня обычно рефрешь стоит, если пришли по рефрешу, то сервер генерит страницу без скриптов. Естественно у меня нет никакого желания писать фейс страницы по новой для статики, там просто элементарный вывод инфы, без навороченных тем (простенький XSLT шаблон генерит страницу по инфе, что юзер аяксом должен был загрузить) и самое плохое - без навигации по всему сайту. Но смотреть можно, если извращенец smile
ИМХО гораздо проще отослать XML с трансформациями, а затем скриптами "улучшить" элементы на странице. Например скрыть все подменю, поставить транслит на форме, включить валидацию и прочее. Пока я не писал ни одного проекта на чистом XML, но форумские "новости" показывют что в принципе уже можно

Цитата(12345c @  24.7.2006,  18:06 Найти цитируемый пост)
если это тоже исходит из вопроса, что нужно пользователю от блока текста.  

Там другая политика была, HTML формы очень ограниченны, без валидации, без вычислений и с инфой о внешнем виде. XForms содержат инфу только о том как предполагаеться работать с контролом, если "запустить действие", то это скорее всего будет кнопка. Возможность собирать нескоько разных "отсылок", валидация и главное формулы (результат которых кстати отображаеться просто как текст, пример когда контролы формы это не "привычные контролы"), позволяющие собрать страницу как в Excel.

Добавлено @ 19:43 
 smile 
Цитата(12345c @  24.7.2006,  18:06 Найти цитируемый пост)
Эти cap-s есть вообще отдельная сруктура

У меня это просто список (таблица) заявленная в базе, по дефолту есть несколько, но админ может задать и больше. Каждый из capabilities это простенький обьект, имеющий isCompatible() и isEqual(), всё что поддерживаеться йзуером (определяеться по его аккаунту + инфа с первой страницы (разрешение экрана etc), правда эта инфа ещё ни одним модулем не пользуеться). Каждый модуль имеет("знает") свои caps и соответственно меняет своё поведение если оно isCompatible. Пока всё однобоко, т.е. на отключение фичь если они не поддерживаються либо сигналим ошибку, но в будущем предпологаю сделать в прямом смысле альтернативное представление модулем от разных caps. Это нужно например для рендера прсто веб страниц и wap страниц на мобилы.
 smile 

Этот офтоп собрать до нормальной мысли и  в отдельный топ... smile 


--------------------
 Опыт - сын ошибок трудных  © А. С. Пушкин
 Процесс написания своего велосипеда повышает профессиональный уровень программиста. © Opik
 Оценить мои качества можно тут.
PM   Вверх
12345c
Дата 24.7.2006, 21:48 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Круглый
****


Профиль
Группа: Vingrad developer
Сообщений: 2018
Регистрация: 26.12.2005
Где: наша не пропадала ?

Репутация: нет
Всего: 101



Да, для отключённого JS и для поисковиков обязательно нужно иметь упрощённую навигацию, отключаемую скриптом.
Форумские новости у меня почему=то в браузере не смотрятся прилично. Наподобие RSS-канала Винграда. Но тот - для фидеров, а новости для кого?

У меня тут проводистя ещё мысль, что одним JS не обойдёшься, нужно делать систему генерации/компиляции сайта или страниц. В частном случае можно запустить билиотеки с чистым некомпилированным JS, но он будет тяжеловесен. Будем поддерживать эти случаи?

Если да, то тот случай, когда отключен JS, рассматривается компилятором и выдаёт простенькую навигацию по структуре сайта, видимую в HTML-е. 
PM WWW   Вверх
Sardar
Дата 25.7.2006, 15:21 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Бегун
****


Профиль
Группа: Модератор
Сообщений: 6986
Регистрация: 19.4.2002
Где: Нидерланды, Groni ngen

Репутация: нет
Всего: 317



Несколько раз перечитал, попытался "полностью охватить идею"... В начале я понял её как спецификацию неких базовых обьектов (например XML тегов), используемых как вёрстку, с точным семантическим значением (смысл) и не имеющих визуальное представление (оно выбираеться из контекста). Идея представилась очень громоздкой и на клиенте её не реализуют.  Обычно делают простую для понимания концепцию рендеров, например рендер статей, рендер таблиц и т.д. Задача такого рендера превратить высокоуровневые обьекты логики в "низкоуровневую" вёрстку под конкретное представление, для этого обьявляються примитивы рендера (базовые элементы). На выходе может быть страница целиком, а может быть краткий XML документ для загрузки аяксом.

Проблема таких рендеров в спецификации примитивов, под каждую задачу они разные, а при расширении рендера приходиться и расширять back-end'ы генерящие вёрстку под конкретные темы. Чем меньше примитивов, тем менее гибкая система, чем их больше, тем больше система напоминает просто вёрстку и следовательно меньше смысла во всём этом. Золотая середина выявляеться в анализе всего что может появиться на странице конкретного сайта, если вариаций в примитивах очень много, то соскавиаем на шаблонизатор с поддержкой выражений. В таком случае реализовать разные темы порой очень сложно.

Сейчас я вижу что ты задумал в целом весь сайт, где каждый ресурс (страница) это обьект на который могут ссылаться. В зависимости от контекста отрисовывать логическую ссылку в меню, выпадающий список и т.д.? Опять же ИМХО очень громоздко и к JS вообщемто не имеет отношения, требуемая вёрстка должна быть сгенерированна рендером на сервере.

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

Цитата(12345c @  24.7.2006,  20:48 Найти цитируемый пост)
нужно делать систему генерации/компиляции сайта или страниц. В частном случае можно запустить билиотеки с чистым некомпилированным JS, но он будет тяжеловесен. Будем поддерживать эти случаи?

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

Опиши конкретней (лучше с примером) как это может работать, возможно я просто не правильно понял smile   


--------------------
 Опыт - сын ошибок трудных  © А. С. Пушкин
 Процесс написания своего велосипеда повышает профессиональный уровень программиста. © Opik
 Оценить мои качества можно тут.
PM   Вверх
12345c
Дата 26.7.2006, 01:25 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Круглый
****


Профиль
Группа: Vingrad developer
Сообщений: 2018
Регистрация: 26.12.2005
Где: наша не пропадала ?

Репутация: нет
Всего: 101



Правильно, я тоже сначала подумал ограничиться структурой, представляя её DIV-ом с параметрами и функциями, но появилась абстракция многостраничного сайта, и пришлось вылезти за рамки клиентского языка. Но если ограничиться в частном случае клиентом - почему громоздко? Я не хочу тащить весь див (или XML) на клиент. Если задача просит часть структуры, ей поставляется часть плюс функции загрузки недостающих частей. Объект получается очень всеобъемлющим и потому тяжёлым, поэтому давай рассмотрим случаи - или компилировать его, оставляя в каждой реализации его часть, или может оказаться случай, когда выгодно иметь все функции подгрузки, если всё на сайте в плане представления данных (контента) использует их. И меню будут брать заголовки из своего объекта и уметь подгружать или показывать подсказки, списки и ветви контента, и части документа будут иметь представление свёрнутости и развёрнутости, и сама страница будет ветвью структуры сайта, подгруженная теми же процедурами.

Имея разные способы реализации - сервер и клиент, мы можем свободно использовать ресурсы того или другого, что нам мешает? Сервер - это традиционное решение, но мы же хотим сделать и опробовать инновационное?

Цитата(Sardar @  25.7.2006,  15:21 Найти цитируемый пост)
По идее скрипты должны быть статичны, если часть не всегда необходима, то лучше разбить библиотеку на файлы.
Общий недостаток библиотек - то ли файлов много, то ли содержимого их. Поэтому в рамках проекта можем рассмотреть случай компиляции библиотеки под проект - файл или файлы окажутся кешированными на страницы сайта, но не будут иметь лишнего. Не используем мы часть функций - выбрасываем из файла на этапе компиляции - построения сайта. Если часть функций с неизвестным заранее вызовом (будут использоваться или нет), в рабочем порядке решаем, засовывать их в общий файл или во второй, тоже фиксированного содержания, чтобы кешировался при последующем использовании.

Добавлено @ 01:31 
Цитата(Sardar @  25.7.2006,  15:21 Найти цитируемый пост)
если вариаций в примитивах очень много, то соскакиваем на шаблонизатор с поддержкой выражений
Я вижу не очень много вариаций, но достаточно много для традиционных задач типа меню. В этом объекте нужно охватить элемент меню (надпись, рисунок), подсказку, аннотацию (начало статьи или ветви документа или раздела), всю ветвь. Или несколько градаций подробности представления. Всё, остальные задачи - как представить, в окне ли, в слое, в потоке - решают другие объекты, глядя на свой контекст.
 
PM WWW   Вверх
Sardar
Дата 26.7.2006, 02:26 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Бегун
****


Профиль
Группа: Модератор
Сообщений: 6986
Регистрация: 19.4.2002
Где: Нидерланды, Groni ngen

Репутация: нет
Всего: 317



Цитата(12345c @  26.7.2006,  00:25 Найти цитируемый пост)
Если задача просит часть структуры, ей поставляется часть плюс функции загрузки недостающих частей.

А ты не подумал что JS это уже гибкий и простой инструмент для того что бы кратко описать требуемую логику? smile
Зачем мне писать некий элемент с туевой хучей представлений которые 99% ближайших пол года не будут использоваться (тема меняеться редко)? Я лучше напишу меню точно под задачу, которое бует отображать точно то, что мне нужно + составлю спецификацию как обращаться к ресурсам на сайте. В итоге пишеться скрипт (не прога smile ) кратко и лаконично связывающий возможности браузера с требованиями сайта.

Но! для простоты реализации хорошо бы обычный рутинный код выносить в библиотеки, в данном случае вижу:

1) Некая концепция DataSource позволяющая без проблем переключать источник инфы для элемента, например аякс или статичный .js. При чём инфа эта не совсем динамическая, сюда входят заголовки меню, подсказки и прочее.

А зачем? Подсказка к опции меню меняеться с опцией меню, само меню генериться на сервере, зачем мне подгружать эту "статику" динамически (да хотя бы кешируемым .js, главное что строиться на клиенте)? А если есть динамика, то она всегда будет динамикой. Кеширование используеться, да, но это прерогатива сервера кешировать отдельные части документа (кстати эту идею опишу позже, впрочем она достаточно тривиальна). К примеру когда то писал меню для нашего FAQ'а, там меню статичное, но перестраиваеться если оно меняеться. Клиент об этом ничего не знает, просто весь код разделён на два скрипта:  логика и данные. Это я так понял что ты хочешь, но разве это нужно для общего сайта. Я признаюсь кроме как в FAQ'е кеширование в скрипте нигде не пользовал smile

Цитата(12345c @  26.7.2006,  00:25 Найти цитируемый пост)
случай компиляции библиотеки под проект 

Но тогда браузер будет видеть это как множество разных скриптов, следовательно будет подгружать один и тот же код множество раз (забивая зря кешь ещё). Приведи примеры из жизни когда разделить скрипты по файлом эффективно было не возможно, всё равно тащился часто лишний код. Просто сам никогда с таким не сталкивался, обычно 90% страниц пользуют единые скрипты (какие то меню, автоматизация и прочее), перебирать "под страницу" никогда не приходилось...
Приходилось дописывать отдельные вставки кода, но мне их проще вставить в саму страницу, чем в отдельный файл.

2) общий базовый "не видимый для юзера" код, позовляющий удобно пользоваться DOM'ом, аяксом, событиями и т.п. не отвлекаясь на примочки браузеров.

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

Цитата(12345c @  26.7.2006,  00:25 Найти цитируемый пост)
Я вижу не очень много вариаций,

Для меню - нет, но ты уже заметил как много всего нужно что бы меню можно было построить как угодно скриптами, оно всё ближе к вёрстке приближаеться. Т.е.  логике приходиться знать как выглядит меню (минимальная структура, типа где заголовок и прочее), вместо того что бы просто указать список опций. ИМХО до сих пор считаю что сверстать под задачу проще. Приведи конкретный пример, попробуем написать, оно "на руках" лучше воспринимаеться и критика более конструктивна.  


--------------------
 Опыт - сын ошибок трудных  © А. С. Пушкин
 Процесс написания своего велосипеда повышает профессиональный уровень программиста. © Opik
 Оценить мои качества можно тут.
PM   Вверх
12345c
Дата 27.7.2006, 19:58 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Круглый
****


Профиль
Группа: Vingrad developer
Сообщений: 2018
Регистрация: 26.12.2005
Где: наша не пропадала ?

Репутация: нет
Всего: 101



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

Цитата(Sardar @  26.7.2006,  02:26 Найти цитируемый пост)
Но тогда браузер будет видеть это как множество разных скриптов


Перебор библиотеки не под страницу, а под сайт происходит. На одном будет подгрузка, на другом нет. А определяется объёмами данных, требуемой оперативностью.

У меня нет примеров использования, но я точно знаю, что в любой библиотеке лишние для задачи скрипты есть. smile

Почему ты представляешь, что после прореживания библ. скрипты будут разные? Будет необходимое количество скриптов, объединяемое в файл. Тут уж от мастерства разработчика зависит, будут ли они дублироваться. Наша задача - выявить общие места, написать на них библиотеку, из которой можно выбрасывать неиспользуемые на сайте операции. Из-за того, что такие глобальные действия трудоёмки, возникает мысль о компиляторе.
Цитата(Sardar @  26.7.2006,  02:26 Найти цитируемый пост)
Т.е.  логике приходиться знать как выглядит меню 
Это ядумаю решать через набор решений. Он будет неуклюжим по сравнению с человеком-разработчиком, но не перегружает сайт лишними кодами, если встроить компилируемость.

Да тут большая работа, если брать те же меню. Для начала можно взять пример свёртки/развёртки/подгрузки статей под заголовки и аннотации. Их видов не очень много - аннотация справа, в слое, содержание в новом окне, в слое со скроллбаром. Раз в 5 более объёмна задача с меню разных типов. К ним примешивается группа задач диспетчера свободного места в окне. Их все решают конкретно и каждый раз. Их надо решать такими глобальными библиотечными методами. С обязательной компиляцией. Разработчик, кстати ей занимается.
 
PM WWW   Вверх
Sardar
Дата 28.7.2006, 02:31 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Бегун
****


Профиль
Группа: Модератор
Сообщений: 6986
Регистрация: 19.4.2002
Где: Нидерланды, Groni ngen

Репутация: нет
Всего: 317



Цитата(12345c @  27.7.2006,  18:58 Найти цитируемый пост)
Это ядумаю решать через набор решений.

А ты сам готов пользоваться такими решениями? smile
Получиться набор клише, по которым можно штамповать типовые страницы, а это ИМХО очень редко используеться, ибо устаревает. Чел просто запустит dreamweaver/frontpage, выберет одну из готовых тем и соберёт "сайт".

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

Цитата(12345c @  27.7.2006,  18:58 Найти цитируемый пост)
Мне надоело писать скрипты, хочу их генерировать 

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

Как вариант можно реализовать систему портежей типа FreeBSD/Gentoo, но без ручных "билдов". Есть некий локальный репозиторий скриптов, все скрипты храняться там и могут быть (им)(экс)портированны в .js скрипты. Каждая импортированная функция разбираеться, находяться все вызовы других функций и "глобальные" переменные. По ним строяться зависимости. Юзер хочет поставить себе прогресбар на страницу:

Код
# jsexport  JProgressBar

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

Как видишь такой набор утилит помог бы брать только необходимый код, но это всё инструменты разработчика, код не должен генериться динамически на сервере. Реализовать достаточно просто на любом скриптовом языке с подключаемым SQLite или подобной БД. ИМХО Python идеален для таких целей. 


--------------------
 Опыт - сын ошибок трудных  © А. С. Пушкин
 Процесс написания своего велосипеда повышает профессиональный уровень программиста. © Opik
 Оценить мои качества можно тут.
PM   Вверх
12345c
Дата 28.7.2006, 12:16 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Круглый
****


Профиль
Группа: Vingrad developer
Сообщений: 2018
Регистрация: 26.12.2005
Где: наша не пропадала ?

Репутация: нет
Всего: 101



Цитата(Sardar @  28.7.2006,  02:31 Найти цитируемый пост)
Это ядумаю решать через набор решений.
А ты сам готов пользоваться такими решениями? smile
Я такими практически не пользуюсь, так как по ним видно, откуда ноги растут. Но если такое применить для чего-то базового (типы меню), то может оказаться, что будет выполнен охват 80% классических решений, и пользоваться ими будет разумно.

Речь не о типовых страницах, а о типовых узлах и скриптах, которые часто не видны (диспетчер пространства окна).

Если времени много, то порекомендовал бы отработать онлайновый редактор. Везде пригодится для встраивания, и надо знать где какие грабли. И, кстати, почему нафоруме динамическая подсветка синтаксиса не используется? Смотрю в код - там HTML, а год назад тут в проекте активно обсуждали JS-подсветку.

Цитата(Sardar @  28.7.2006,  02:31 Найти цитируемый пост)
генерировать ли скрипты
В данном случае говорил о генерации по шаблонам, а есть задача (непонятно с какого боку подойти) об общей генерации и оптимизации кода независимо от языка.

В случае нашей генерации я представляю, что можно начать с полуавтоматической системы "набор целей - набор реализаций". В новом проекте к каждому узлу (меню, страницы) пишутся параметры-цели, названия которых берутся из словаря Frmework-а. Глядя на них, оболочка предлагает и выбирает по совместимостям наборы реализаций. После ручного рыбора решений оболочка идёт дальше, насколько может - приводит в соответствие какие-либо параметры, компилирует файлы библиотеки (точнее, это называется линкованием уже, когдане исключаются неиспользуемые модули, но тут на уровне частей файлов). Систему затем развиваем, дописывая всё новые недостающие действия. Остаётся меньше ручной работы. В конце приходим к системе, где программирования не нужно, только задание параметров в диалоге.

Да, примерно то, что ты описал с прогресс-баром, только не прогрессбар нужен, а решение с показом прогресса, а там предлагается - бары, заставки или их отсутствие, если время ожидания мало. Вид затем уточняет пользователь на следующем шаге выбора. При этом в начале пользователь должен оказаться программистов, потому что оболочка не будет уметь строить зависимости, линки.

По мере развития код может дойти до уровня динамической генрации на сервере. (Если не успеет устареть.) 
PM WWW   Вверх
Sardar
Дата 28.7.2006, 12:39 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Бегун
****


Профиль
Группа: Модератор
Сообщений: 6986
Регистрация: 19.4.2002
Где: Нидерланды, Groni ngen

Репутация: нет
Всего: 317



Цитата(12345c @  28.7.2006,  11:16 Найти цитируемый пост)
В конце приходим к системе, где программирования не нужно, только задание параметров в диалоге.

Оно устаревает, JS вообще быстро устаревает, специфика окружения.

Вообщем начали с некого стандарта общей высокоуровневой разметки "оторванной" от представления (выбор по контексту), а  кончили софтиной на подобии CVS которая может отслеживать зависимости и описание блоков кода (сниплеты, функции и т.д.), и собирать скрипты под задачу. Работа интересная если не одно но: такой инструментарий нужен для больших проектов, которые на JS практически не встречаються. Скрипты обычно не большие, их можно охватить в голове. А пользователь который хочет использовать чужие скрипты у себя просто закачает их из инета, вместо постоянно устаревающих в репозитории. ИМХО как то не очень получаеться smile 


--------------------
 Опыт - сын ошибок трудных  © А. С. Пушкин
 Процесс написания своего велосипеда повышает профессиональный уровень программиста. © Opik
 Оценить мои качества можно тут.
PM   Вверх
12345c
Дата 28.7.2006, 16:16 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Круглый
****


Профиль
Группа: Vingrad developer
Сообщений: 2018
Регистрация: 26.12.2005
Где: наша не пропадала ?

Репутация: нет
Всего: 101



Это годится и для мелких проектов, особенно тем, что раздувать их не будет.

Останется опыт создания и костяк системы. Чтобы он не устарел, нужна та вторая идея "об общей генерации и оптимизации кода независимо от языка". которая позволяет переводить систему на более новую версию языка без переписывания кода. (Результат которой позволял бы...)

Главное, что такая система позволит вставлять накрученные инструменты, оставаясь в рамках разумных размеров кода, туда, куда вручную их ставить было бы лениво. 
PM WWW   Вверх
  
Ответ в темуСоздание новой темы Создание опроса
0 Пользователей читают эту тему (0 Гостей и 0 Скрытых Пользователей)
0 Пользователей:
« Предыдущая тема | ViJio - фреймворк для JS | Следующая тема »


 




[ Время генерации скрипта: 0.1506 ]   [ Использовано запросов: 21 ]   [ GZIP включён ]


Реклама на сайте     Информационное спонсорство

 
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности     Powered by Invision Power Board(R) 1.3 © 2003  IPS, Inc.