vitus_wagner | Coder must die

Тут Алексей Печников замучал меня вопросами, почему для StillLife выбрана именно такая архитектура.

Поэтому я решил признаться в своем тайном замысле. Основная цель - убить web-кодера, как профессию.

Первым пристрелочным выстрелом в эту сторону был Communiware. Это был очевидный перелет. Концепция "информационного супа" предложенная для Коммунивера Андреем Акопянцем настолько велика и могуча, что освоить её в совершенстве могут только отдельные гении вроде

ailev. Ну и ресурсов тоже кушает будь здоров.

Это не то, что нужно отдельному юзеру.

Поэтому StillLife в значительной мере Communware наоборот. Если в Communiware в базе хранились не только данные, но и программы их представления (шаблоны), то в StillLife базы данных нет вообще, если не считать пары DBM-ок, используемых для аутентификации пользователей.

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

В общем, классическая попытка взять цель в вилку.

Понятно, что получится недолет. Даже сейчас видны целые классы сайтов, реализация которых на базе концепции StillLife принципиально невозможна, например Internet-магазины. Web-форум - это предел интерактивности, которого можно добиться на базе такой концепции. Именно поэтому разработка StillLife начата именно с форумного движка. Дальнейшее - блоги и средства управления контентом традиционного сайта - будет проще.

Основное, что лежит в основе - антитеза концепции, выдвинутой

ailev лет 6-7 назад "Сайт - это программа".
Как раз эта концепция, которая в общем-то в то время носилась в воздухе, приводит к тому, что вокруг WWW кормится армия криворуких кодеров. Раз сайт это программа (при этом каждый сайт - отдельная, уникальная программа), каждому сайту нужен программист. Хороших программистов на все сайты не напасешься, значит большая часть сайтов, в том числе и интересных содержательно, будут написано плохими программистами, а следовательно будут плохими, неудобными для пользователя программами.

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

Примерно в этом направлении сейчас двигаются Google, SixApart и другие подобные крупные сервисы.
Но они - злобные проприетарщики. Хотя сейчас очевидно, что создать хорошее web-приложение без использование OpenSource технологий практически невозможно, они ухитрились обойти GPL посредством исполнения программ только у себя на сайте. Раз пользователь не получает исполняемой копии программы, он не вправе требовать и доступа к исходным текстам, даже если 90% кода - GPL.

Кроме того, решения применяемые LJ, Google и другими крупными сервисныи компаниями в WWW требуют соответствующей аппаратной базы. Именно этим объясняется незначительный успех клонов ЖЖ, базирующихся на его коде. Вербицкий может взять исходники ЖЖ, которые Фитцпатрик честно открыл, но у него нету и не может быть денег для создания датацентра, аналогичного калифорнийскому датацентру ЖЖ. Поэтому Vendor Lock In в классическом виде.

Для полноценной реализации концепции "сайт - это документ", требуется программа обработки этого документа, способная выполняться на любом, доступном пользователю компьютере - будь то shared hosting, будь то домашний компьютер с широкополосным подключением к интернету. Лучше конечно, иметь несколько разных программ, адаптированных к разным средам выполнения, но работающих с одинаковым форматом документа. Именно работающих с одинаковым форматом документа. Поэтому столь распространенные нынче в веб-строительстве РСУБД не годятся. Можно создать схему БД, которая будет работать в mySQL, PostgreSQL и Oracle, но с перетаскиванием её будут некоторые проблемы - потребуются специальные срества импорта/экспорта. Да и работать она будет неэффективно, так как она будет вынуждена на каждом сервере не использовать именно те возможности, которыми он наиболее силён - из-за отсутствия этих возможностей в других серверах, совместимость с которыми поддерживается.

Flat | Top-Level Comments Only

Очевидные возможные грабли - развитие по пути PHP. Когда к _документу_ потихоньку добавляются элементы _программы_, а в результате получается система без разделения программы и данных - причём именно там, где классической "архитектуры Фон Неймана" изначально не было и она реально не нужна.

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

Лично моё мнение: как минимум надо принять жёсткое правило "в одном файле не должно быть кода и данных вообще никогда". То есть, если это шаблон - там есть HTML, в нём (HTML compatible способом) указатели на вставляемые _данные_, но нет ни какой-либо условности, ни какой-лиюо последовательности исполнения - ничего, что не свойственно "голым" данным.

Если же давать пользователю возможность скриптинга, например для доступа к БД - то в отдельных файлах.

В этом случае, кстати, можно делать скриптинг на том или ином существующем языке. Языки с ограниченными возможностями, преднащзначенные именно для встраиывемых в системы скриптов, существуют - мне известен как минимум Lua. Этот вариант уменьшает Learning curve и тем увеличивает потенциальную базу пользователей.

Кстати, а нельзя ли как-то сделать шаблоны совместимыми с визуальными редакторами HTML? Или хотя бы "конвертируемыми из" визуально редактируемых HTML файлов? Да, я понимаю, что так хороший HTML-код не делается. Но далеко не все желают учить HTML ради оптимизации качества кода - мне, например, ради личного сайта это делать влом, и даже если я наконец найду время на сайт, он будет сделан в OO.org.

Вообще говоря, то что ты предлагаешь у меня в основном УЖЕ есть. От шаблона требуется чтобы он проходил w3c-шный валидатор. А раз он проходит w3c-шный валидатор, то и визуальный редактор HTML с ним наверняка справится.

Что касается скриптования, то я считаю что наиболее правильным скриптовым языком именно для пользователей, является использование JavaScript (в смысле server-side). Тут, правда, надо сильно думать о том, какую объектную модель подсунуть. Очевидно, что модель документа должна быть максимально совместимой с таковой в браузере (не важно, хорошая она или плохая, важно что пользователю все равно её учить). А вот как быть с моделью БД, файловой системы и т.д. - думать надо.

Да, кстати, хороший HTML-код с помощью визуальных редакторов делать можно. Правда, для этого нужно знать что такое хороший HTML-код. Многие редакторы, например Allitaire HomeSite, не мешают делать хороший код. Поэтому грамотный веб-дизайнер вооруженный таким редактором будет делать хороший код быстрее, чем в текстовом редакторе общего назначения (даже и продвинутом). К сожалению, технологии, навязывающей деланье хорошего кода примерно с той же степенью интенстивности, с какой LaTeX навязывает деланье качественной структуры документа, пока не изобретено.

Генерацией контента занимаются не только грамотные веб-дизайнеры. А интерфейса CMS, который был бы сравним по возможностям (даже только нужным мне для простого контента) с локальным визуальным редактором, я пока не видел. (Но я могу быть неправ).

Писать вики-код мне ничуть не легче, чем HTML-код. То есть, конечно, вики-код легче сделать качественным. Я имею в виду другое - и то, и то примерно равно делает создание контента более тяжёлым.

Вот генерация контента - это совсем другой вопрос. Мы вроде говорили о шаблонах. Их пишут все-таки web-дизайнеры. Предпочтительно, грамотные, а там как повезет.

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

Я туда написал. Но мне несколько сложно следить за дискуссией, пока нет сообщений на email. Поэтому здесь я оперативнее, иногда на дни.

Вот CSS -- это код или данные? Использование его для условного показа разных кусков HTML -- штатная фича интерфейса гугль мейла. А крайне кривым непортабельным хаком можно даже заменять одни данные на другие. И никакого джаваскрипта!

... Посетителей не будят ...

Кстати, позавчера был (я узнал только вчера постфактум) Naked CSS Day -- участвующий народ на один день убирал со своих сайтов весь CSS, демонстрируя голую логическую структуру (если было, что демонстрировать). Именно чтобы подчеркнуть различие смысла и оформления.

... Регулярно выражаясь ...

Coder must die

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject