Итак, о проекте нового движка форума

 
1 2 3 4 5
RU Balancer #08.10.2004 23:19  @Serge Pod#08.10.2004 13:39
+
-
edit
 

Balancer

администратор
★★★★★
S.P.>Глобальные изменения в GUI, с точтки зрения юзера, будут?[»]

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

Balancer

администратор
★★★★★
Centuriones>Будет ли проект рассчитываться на плоское отбражение или нет? Дело в том, что с точки зрения юзверя нормальный иерархический форум, типа ВИФ'ов удобнее плоского.

Ни в коем случае :D Многолетний опыт показывает, что линейные обсуждения намного удобнее древовидных. Во-первых, древовидное обсуждение тяжело отслеживать не в реальном времени (например, что нового появилось за последние пару суток твоего отсутствия), во-вторых, деревья крайне неэргономичны (много лишних кликов). В-третьих, напрочь теряется чувство хронологии. И т.д. и т.п., в общем :)

Кстати, в пользу моего мнения говорит и факт фактического отмирания древовидных форумов. Ещё лет пять назад древовидные движки даже преобладали над плоскими. Сегодня - их практически не осталось :)
 
RU Centuriones #08.10.2004 23:34
+
-
edit
 

Centuriones

опытный

Balancer:
Centuriones>Будет ли проект рассчитываться на плоское отбражение или нет? Дело в том, что с точки зрения юзверя нормальный иерархический форум, типа ВИФ'ов удобнее плоского.

Ни в коем случае (IMG:http://airbase.ru/forum/smilies/biggrin.gif) Многолетний опыт показывает, что линейные обсуждения намного удобнее древовидных. Во-первых, древовидное обсуждение тяжело отслеживать не в реальном времени (например, что нового появилось за последние пару суток твоего отсутствия), во-вторых, деревья крайне неэргономичны (много лишних кликов). В-третьих, напрочь теряется чувство хронологии. И т.д. и т.п., в общем (IMG:http://airbase.ru/forum/smilies/smile.gif)

Кстати, в пользу моего мнения говорит и факт фактического отмирания древовидных форумов. Ещё лет пять назад древовидные движки даже преобладали над плоскими. Сегодня - их практически не осталось (IMG:http://airbase.ru/forum/smilies/smile.gif)
 


Не факт, и могу поспорить. Соображения пошлю личным сообщением. :)
Раньше были времена,
А теперь мгновения.
Раньше поднимался дух,
А теперь давление.
 
+
-
edit
 
+
-
edit
 

Vanish

новичок
Да хотелось бы тоже почитать доводы :)
 
eldar.mmail.ru
я не про, не спец по РНР, но помочь, готов и постараюсь...

GPL форева, опен сурс форева...
 
RU Centuriones #09.10.2004 03:52
+
-
edit
 

Centuriones

опытный

ХОРОШО. :)
Раньше были времена,
А теперь мгновения.
Раньше поднимался дух,
А теперь давление.
 
RU Наблюдатель #09.10.2004 11:15
+
-
edit
 

Наблюдатель

новичок
Древовидная, линейная...
Это уход в сторону. Готовое решение у вас перед глазами - на верхней планке:
Outline · [ Standard ] · Linear+
и внизу: Lo-Fi Version

Помнится, Балансер писал о гибкости конфигурирования... Зачем спорить "что лучше?", когда можно решение этого вопроса свалить на плечи каждого юзера в отдельности... Пусть он выберет себе... по вкусу. Все возможные методы отображения должны присутствовать в движке! (вплоть до TIFF-отображения... а вдруг он по факсу конфу смотрит... шутка, с долей...)
 
RU Наблюдатель #09.10.2004 11:38
+
-
edit
 

Наблюдатель

новичок
И ещё...

Можно сделать так, чтобы потенциальный клиент продукта, зайдя на сайт разработчика в раздел Download, увидел бы обширную страницу конфигурации с чекбоксами напротив важных пунктов. Читая подсказки, он бы конфигурировал свой пакет под свои нужды из широкого списка предлагаемых ему "кубиков".
"Так, мне нужен этот узел и эти два..., джава... нет, показывать я буду по другому... этот узел подходит... Ага, и этот я задействую..." Собрав таким образом чиста-под-себя, пакет инсталляции, он его может скачать и установить. Если что-то пойдёт не так, то он докачает себе необходимый узел...



дописано 9 окт 14:40
Я не исключаю присутсвия в списке заранее сконфигурированных пакетов:
- Быстрая Конференция без графики
- Не очень быстрая конфа с графикой
- Компактная с графикой (малое диск.пространство)
- Ресурсоэкономная без джава.
....
 
Это сообщение редактировалось 09.10.2004 в 14:45
+
-
edit
 

Balancer

администратор
★★★★★
Хорошая идея. Попробуем реализовать :D
 
RU Наблюдатель #09.10.2004 14:27
+
-
edit
 

Наблюдатель

новичок
Если "хорошая идея", то нужно выделить по одному человеку на каждый узел. Этот человек "ведёт" узел постоянно, соотносясь при этом с политикой проекта. Учитывает все изменения политики и координирует предложения-коды коммюнити данного узла. Занимается окончательным монтажом узла.

Отсюда структура команды:
Конкретный узел под управлением конкретного человека - члена команды разработчиков. Права и голоса членов команды равны. Ими управляет шеф - Главный разработчик.
Каждому члену команды полезно придать заместителя - в его обязанностях ведение документации узла, факи, хелпы, описания... Он - модератор темы узла на движке Wiki и редактирует все изменения-дополнения текста поступающие от собственного коммюнити (кому не совсем понятно - спрашивайте подробности - я опишу).

Я закинул информацию о проекте на ресурс, который поддерживает PGP (все реинкарнации - от платной PGP до опенсорсной GnuPG) с таким прицелом, что кто-то из них войдёт в команду и будет вести узел цифровых подписей, шифрования и пр. защиты приватности... Конечно, на данном этапе это не кажется важным узлом, но... мы ведь не завтра умрём..., а послезавтра это может стать мощным плюсом движка.
 
Это сообщение редактировалось 09.10.2004 в 14:37
RU Centuriones #09.10.2004 15:40  @Наблюдатель#09.10.2004 11:15
+
-
edit
 

Centuriones

опытный

Наблюдатель>Древовидная, линейная...
Наблюдатель>Это уход в сторону. Готовое решение у вас перед глазами - на верхней планке:
Наблюдатель>Outline · [ Standard ] · Linear+
Наблюдатель>и внизу: Lo-Fi Version
Наблюдатель>Помнится, Балансер писал о гибкости конфигурирования... Зачем спорить "что лучше?", когда можно решение этого вопроса свалить на плечи каждого юзера в отдельности... Пусть он выберет себе... по вкусу. Все возможные методы отображения должны присутствовать в движке! (вплоть до TIFF-отображения... а вдруг он по факсу конфу смотрит... шутка, с долей...)[»]
Наблюдатель>Древовидная, линейная...
Наблюдатель>Это уход в сторону. Готовое решение у вас перед глазами - на верхней планке:
Наблюдатель>Outline · [ Standard ] · Linear+
Наблюдатель>и внизу: Lo-Fi Version
Наблюдатель>Помнится, Балансер писал о гибкости конфигурирования... Зачем спорить "что лучше?", когда можно решение этого вопроса свалить на плечи каждого юзера в отдельности... Пусть он выберет себе... по вкусу. Все возможные методы отображения должны присутствовать в движке! (вплоть до TIFF-отображения... а вдруг он по факсу конфу смотрит... шутка, с долей...)[»]

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

2 Balancer

>Ни в коем случае (IMG:http://airbase.ru/forum/smilies/biggrin.gif) Многолетний опыт показывает, что линейные обсуждения намного удобнее древовидных. Во-первых, древовидное обсуждение тяжело отслеживать не в реальном времени (например, что нового появилось за последние пару суток твоего отсутствия), во-вторых, деревья крайне неэргономичны (много лишних кликов). В-третьих, напрочь теряется чувство хронологии. И т.д. и т.п., в общем (IMG:http://airbase.ru/forum/smilies/smile.gif)

А вот тут надо выбирать - что важнее "логика" или "хронологичность" процесса обсуждения. Опять же привожу в пример ВИФ'овский движок. Там, обсуждение нормально отслеживается и не в реальном времени. Я не говорю, что он идеал, но многие, кто регулярно ходят на VIF2, VIF2NE говорят, что "плоскодонки" - отстой и рассчитаны на детей. Я специально сегодня с утра обзвонил многих своих знакомых. Здесь тоже, есть привычка, но логика - есть логика. Недостатки, перечисленные тобой, тоже есть в наличии, но с ними мирятся там - где логика важнее.

>Кстати, в пользу моего мнения говорит и факт фактического отмирания древовидных форумов. Ещё лет пять назад древовидные движки даже преобладали над плоскими. Сегодня - их практически не осталось (IMG:http://airbase.ru/forum/smilies/smile.gif)
Естественно, люди соблазняются на красоту и внешний антураж, тем более что многие "плоскодонки" бесплатны, когда, например, за ВИФ'овский движок надо платить (если верить тому, что выставлено у Новика).

P.S. Приведенное выше дублирование в цитировании я специально оставил, дабы обратить внимание администрации на появившийся глюк. Ранее этого не было, причем еще несколько дней назад. :)





Раньше были времена,
А теперь мгновения.
Раньше поднимался дух,
А теперь давление.
 
RU Наблюдатель #09.10.2004 19:25
+
-
edit
 

Наблюдатель

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

Я сейчас их всех посылаю на тестовую конфу (как и эта на втором движке инвижн) и они радуются кто ло-фи-версией (да-да, я именно об этом писала, спасибо!), кто линейной... Кому смайликов побольше, кто требует их вообще убрать... Короче, полный атас! И если юзер сможет настроить себе такие мелочи, то админу будет дольше и крепче спаться... А кого из юзеров эти вещи не колышут - для тех и будет тот расклад, который выберет админ... Админ в первую очередь делает ДЛЯ ЛЮДЕЙ - юзеров, а не для себя, "что он хочет"... Его задача обеспечить комфортное общение на главную тему конференции. А "комфорт" - это дело вкуса, о чём собственно, спорить и не принято - каждый его понимает по своему. Если есть возможность угодить всем - то почему бы этого не сделать? Модно, отстойно - это вы юзерам будете доказывать... а они после этого будут от вас уходить ко мне... Я их приласкаю и уважу... (примеры я привёл честные, не выдуманные)

Сорри, спор принципиальный и я не имею ввиду никого из присутсвующих (я, ко мне, ты, от тебя - понятия абстрактные, для более полного понимания момента)
 
RU Centuriones #10.10.2004 11:38
+
-
edit
 

Centuriones

опытный

2 Наблюдатель

Я естественно не админ конференции, но разница между "ёлкой" и "доской" принципиальная. И это не просто отображение информации, но работа в конкретной системе (не среде, а именно в системе). Где-то лучше "доска", где-то лучше "ёлка". Смотреть - это одно, а работать - совсем другое. Но с точки зрения работы "ёлка" и "доска" несовместимы. Тут могут быть лишь улучшения отображения, но принципиальная разница все равно останется. Как пример достаточно взять любую тему на Авиабазе, с достаточным числом сообщений, и аналогичную ветку с VIF2NE и сравнить их как в плоском виде, так и в иерархическом. А потом оценить информативность (предварительно с ВИФ'овских сообщений убрав шапки, играющие роль своеобразной подсказки, и отсутствующие в iPB).

Наблюдатель>А "комфорт" - это дело вкуса, о чём собственно, спорить и не принято - каждый его понимает по своему. Если есть возможность угодить всем - то почему бы этого не сделать?
Это то так, только в чем угождать?. И в какой мере угождать? Стоит ли потакать вкусам, которые преходящи, или нет?

P.S. (Balancer'у) Для обсуждения "форм отображения", думается надо создать отдельную ветку, поскольку нынешняя, как я понял, более предназначениа для "предложений", чем для "обсуждений".

Раньше были времена,
А теперь мгновения.
Раньше поднимался дух,
А теперь давление.
 


Ненавижу PHP. Уж лучше Це тогда!


Окончательную версию PHP на си без проблем можно переписать...
А если сразу на си начинать, imho разработка на энное кол-во лет растягивается.



Кроме того, очень и очень многие решения, уже встроенные в PHP там придётся писать самостоятельно, с нуля.


Шаблонизаторы и т.д., на си заново велосипед придется изобретать
 
RU Наблюдатель #10.10.2004 13:39
+
-
edit
 

Наблюдатель

новичок
Centuriones, ты знаешь, по большому счёту, ПОКА наш спор пустой. Поясню. Если работа будет двигаться в сторону создания отдельных узлов из которых клиент сможет собрать НЕЧТО, то этот наш спор всего навсего не тему "писать узел ёлка-отображение?". В конце-концов, кому нужно, тот и напишет. Это непринципиально для политики создания движка. Пусть будет ПЕРВЫМ какой угодно узел отображения.
Если ты настаиваешь, то я "сдаюсь"... (Это ёлка?)


эта часть может быть удалена---
Это ещё и намёк на то, любой желающий уже сейчас может начинать творить нечто, с его точки зрения, полезное. Это "полезное" (утилита?) затем может быть принято Руководителем проекта как готовый узел... (Ау, Руководитель!) Подозреваю, что Руководитель предложит этому "любому желающему" возглавить дальнейшую работу по поддержке этого его узла.

 
IL Serge Pod #10.10.2004 23:58
+
-
edit
 

Serge Pod

администратор

Давайте определимся с требованиями по ядру. Что оно должно делать и что не должно. Потом перейдем к модулям. А на каком языке писать сейчас не важно.
In knowledge we trust!  
RU Balancer #11.10.2004 17:48  @Serge Pod#10.10.2004 23:58
+
-
edit
 

Balancer

администратор
★★★★★
Guest>Окончательную версию PHP на си без проблем можно переписать...
Guest>А если сразу на си начинать, imho разработка на энное кол-во лет растягивается.

Переписать тоже будет очень нелегко.

Наблюдатель>В конце-концов, кому нужно, тот и напишет. Это непринципиально для политики создания движка. Пусть будет ПЕРВЫМ какой угодно узел отображения.

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

Наблюдатель>Это ещё и намёк на то, любой желающий уже сейчас может начинать творить нечто, с его точки зрения, полезное. Это "полезное" (утилита?) затем может быть принято Руководителем проекта как готовый узел... (Ау, Руководитель!) Подозреваю, что Руководитель предложит этому "любому желающему" возглавить дальнейшую работу по поддержке этого его узла.

Для этого надо будет формализовать механизм "узлов" :) Пока интерфейс формализован только для тэгов разметки. Вот их уже может писать любой желающий.

S.P.>Давайте определимся с требованиями по ядру. Что оно должно делать и что не должно. Потом перейдем к модулям. А на каком языке писать сейчас не важно.[»]

Ну, вроде бы уже описано всё. :D Ядро занимается связкой модулей и обеспечивает для них платформеннонезависимый интерфейс к БД. Т.е. в зависимости от запрашиваемого URL вызывает тот или иной обработчик, будь это показ страницы или изменение каких-то данных. Модули, в свою очередь, работая через функции ядра имеют высокоскоростной доступ к тем или иным данным. Так что тут, скорее, речь нужно вести о требованиях конкретных модулей.

Думаю, пора мне составлять список "доверенных лиц", заводить закрытый форум и выкладывать туда исходники того, что есть :)
 
RU Наблюдатель #11.10.2004 19:25
+
-
edit
 

Наблюдатель

новичок
Для этого надо будет формализовать механизм "узлов"
 

Ядро занимается связкой модулей и обеспечивает для них платформеннонезависимый интерфейс к БД
 

Вот-вот-вот!!! Узел=модуль. Значит первоочередная задача и обсосать этот самый интерфейс... хм... создать "шину", на которую будут вешаться модули. Я так понимаю, что из этого уже что-то есть (или всё уже есть).

Думаю, пора мне...
 

Конечно, "составлять" и "заводить", а здесь - общее место, типа "Велкам!" и т.п. флеймище... (не значит глупости). И не надо расстраиваться на тему малопосещаемости - я уверен, народ подтянется сразу после хоть и небольших, но результатов...

Есть у кого-то опыт составления этой самой GPL-лицензии? Может нужно сходить на опенсорсные проекты и с ребятами поговорить? Что там у нас есть? Мозилла... русская команда... Вакка... русская команда... Что ещё?
 

dreik

новичок
кодер из меня никакой, но вот как бета тестер вроде ничего :) да и генератор идей иногда включается :) так что топик ушёл в закладки :) кстати, может стоит повесить sourcesafe? или еще какой-либо tracker? или же зарегистрировать проэкт на sourceforge, думаю что так удобней будет всем разработчикам :)
 
IL Serge Pod #12.10.2004 00:10
+
-
edit
 

Serge Pod

администратор

Vanish>>Остальные наработки читаю, из них вывод сделал, что будет использован ООП подход при разработке, очевидно, что что то очень близкое к MVC модели.
Balancer>Не слышал про MVC, или слышал, но не ассоциирую название :)

Концепция Model - View - Controller

Я не очень представляю как работают форумы, так что будет много вопросов.
Ядро.
1. Получает запросы клиентов напрямую или будет промежуточный модуль?
2. Общается с базой данный через промежуточный модуль, который может мненяться в зависимости от типа БД?
3. Дайте примеры других подключаемых модулей.

P.S. Про Sourceforge - идея хорошая, сам хотел предложить, но там вроде все дела на английском нужно вести.
In knowledge we trust!  
Это сообщение редактировалось 12.10.2004 в 00:27
+
-
edit
 

Balancer

администратор
★★★★★
S.P.>Я не очень представляю как работают форумы

Разные - по-разному. Чаще всего - совершенно непродуманная каша :) В нашем варианте будет примерно так:

S.P.>1. Получает запросы клиентов напрямую или будет промежуточный модуль?

Примерный механизм создания страницы форума "с нуля" (сейчас страницы сайта создаются также, фактически это описание работы нынешнего движка Авиабазы):
  • Идёт обращение к несуществующей странице. Скажем, её ещё нет совсем или, она была удалена при очередном обновлении или проверка дат модификации и прочих флагов указывают, что её нужно создать с нуля.
  • Вызывается скрипт-обработчик запросов. Или непосредственно (через mod_rewrite - в Апаче есть возможность переадресовывать страницы по маске с их реального адреса на другой, например, можно вызвать для всех страниц один скрипт, который и займётся их отображением) или как обработчик ошибки "404 - страница не найдена" (аналогично - вместо стандартного сообщения об ошибке вызывается скипт, который что-то сделает).
  • Скрипт производит все нужные предварительные вычисления, чтобы понять, что конкретно ему требуется показать.
  • Скрипт делает запрос через интерфейс к БД на получение нужных ему данных. Например, текста страницы или набора постингов, которые должны быть на этой странице.
  • Скрипт формирует из сырых данных готовых HTML-код страницы, сохраняет его в кеш и выдаёт браузеру.


  • В дальнейшем, при обращении к этой страницы, пока она не изменится, информация будет выдаваться из кеша.


S.P.>2. Общается с базой данный через промежуточный модуль, который может мненяться в зависимости от типа БД?

Сейчас у меня непосредственно код, работающий с данными и БД разделяют два уровня. Первый (низкий) уровень - это непосредственная работа с БД, отделяющая синтаксис работы с конкретной БД от клиентской программы. Обеспечивает простейшую работу с данными в духе "сохранить ассоциативный массив", "загрузить ассоциативый массив", "получить данные", "записать данные" и т.п. Примеры:
code php
  1. <?
  2. $db = new DataBase;
  3. // сохранить значения идентификатора пользователя и пароля в таблицу 'passwords'
  4. $db->insert('passwords', array('user'=>1, 'password'=>'test'));
  5.  
  6. // вернуть пароль пользователя с идентификатором 1 из таблицы 'passwords'
  7. $db->get_value('passwords', 'user', 1, 'password')
  8.  
  9. // и т.д.
  10. ?>


Второй уровень - это работа с моим "объектным" форматом БД, надстройка над первым:
code php
  1. <?
  2. $hts = new DataBaseHTS;
  3. // "нормализация" URL. "www.airbase.ru/index.php" превратится в "http://airbase.ru/"
  4. $uri = $hts->normalize_uri($uri);
  5.  
  6. // Получить заголовок страницы $page:
  7. $title = $hts->get_data($page, 'title');
  8.  
  9. // получить массив - список идентификаторов дочерних страниц у данной:
  10. $childs = $hts->get_data_array($page,'child');
  11.  
  12. // Связать по навигаии две страницы. $page1 становится "родителем" у $page2, а $page2 - "дочерней страницей" у $page1:
  13.  
  14. $hts->nav_link($page1, $page2);
  15. ?>


S.P.>3. Дайте примеры других подключаемых модулей.

От балды по разным классам:
  • Генерация страницы из исходника
  • Редактор страницы
  • Отправка сообщения на форум
  • Показ всех страниц форума, в заголовках которых есть нужные ключевые слова
  • Показ всех страниц, с которых были переходы на эту
  • Обработка переноса топика из одного форума в другой.
 
Мне кажется для улучшения управляемости и эффективности проекта лучше создать страничку. Там можно двигаться от общих черт к реализации. На форуме всё это затеряется и распылится.
Идея такова - страница с описанием сущности - что хотелось бы получить - кто занимается - на какой стадии - какие проблемы - контакты - ссылки на обсуждение деталей на форуме.
Тогда будет всё структурировано и дело пойдёт быстрее.

S.P.>>Я не очень представляю как работают форумыBalancer>Разные - по-разному. Чаще всего - совершенно непродуманная каша :) В нашем варианте будет примерно так:
S.P.>>1. Получает запросы клиентов напрямую или будет промежуточный модуль?
Balancer>Примерный механизм создания страницы форума "с нуля" (сейчас страницы сайта создаются также, фактически это описание работы нынешнего движка Авиабазы):
Balancer>* Идёт обращение к несуществующей странице. Скажем, её ещё нет совсем или, она была удалена при очередном обновлении или проверка дат модификации и прочих флагов указывают, что её нужно создать с нуля.
Balancer>* Вызывается скрипт-обработчик запросов. Или непосредственно (через mod_rewrite - в Апаче есть возможность переадресовывать страницы по маске с их реального адреса на другой, например, можно вызвать для всех страниц один скрипт, который и займётся их отображением) или как обработчик ошибки "404 - страница не найдена" (аналогично - вместо стандартного сообщения об ошибке вызывается скипт, который что-то сделает).
Balancer>* Скрипт производит все нужные предварительные вычисления, чтобы понять, что конкретно ему требуется показать.
Balancer>* Скрипт делает запрос через интерфейс к БД на получение нужных ему данных. Например, текста страницы или набора постингов, которые должны быть на этой странице.
Balancer>* Скрипт формирует из сырых данных готовых HTML-код страницы, сохраняет его в кеш и выдаёт браузеру.
Balancer>* В дальнейшем, при обращении к этой страницы, пока она не изменится, информация будет выдаваться из кеша.
S.P.>>2. Общается с базой данный через промежуточный модуль, который может мненяться в зависимости от типа БД?
Balancer>Сейчас у меня непосредственно код, работающий с данными и БД разделяют два уровня. Первый (низкий) уровень - это непосредственная работа с БД, отделяющая синтаксис работы с конкретной БД от клиентской программы. Обеспечивает простейшую работу с данными в духе "сохранить ассоциативный массив", "загрузить ассоциативый массив", "получить данные", "записать данные" и т.п. Примеры:
 


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

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

Balancer

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

На создание страницы из имеющихся данных аутентификации никакой не нужно. Она нужна при изменении данных и при ограничении доступа к конкретному ресурсу.

Tolka>Ну и по административным моментам. Начинать мне кажется нужно с чётких задач по пунктам - что должено делать сие ПО. Дать себе труд формализовать это до отмирания всех двойных толкований и недоговорок.

Ищутся тактики (по Рейнину), предпочтительно - Доны Кихоты, Максы, Бальзаки и Штирлицы :)

>Далее уже прикидывать путь по которому запрос из инета превращается в контент высылаемый пользователю.

Это как раз самое простое :) Сложнее - со всеми проверками и отработками при модификации контента. Ещё сложнее - подать всё в красивом виде. Хороший скин, продуманный интерфейс...
 
+
-
edit
 

Vanish

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

А как же фишечки вида Привет, Бобер! У вас 10 новых писем... На форуме присутствуют, тему читают... Вывод кнопочек в зависимости от пермишенов...
 
1 2 3 4 5

в начало страницы | новое
 
Поиск
Настройки
Твиттер сайта
Статистика
Рейтинг@Mail.ru