воду вы какую-то пишите, ребята, прям не узнаю [vs]. Давайте поговорим о модульности в плане повторного использования кода.
Koc, модульность ТС и модульность для повторного использования кода параллельны друг другу. В твоем случае принцип ООП дроби код на как можно более мелкие куски. Повторное использование будет стремится к таковому у родных операторов языкам У ТС, как я понял, вопрос в плане галлерей, гостевых книг, системы авторизации и т.п.. Т.е. крупных законченных блоков. И на него, в общих чертах, ответил [vs] в своем первом сообщении.
вот у нас есть статические странички. Они в админке выводятся деревом. Есть разделы новостей - тоже древовидная структура. Есть категории товаров - опять дерево. Это как бы символизирует нам что... Должны быть какие-то общие части. Но в то же время странички можно перетаскивать одна в другую, а разделы - нет. На какие именно части ты разбил бы этот код? Примерно.
на 3 ес-но, разные функции выполняются другое дело, что делать если нужно наладить взаимодействие между этими частями, тогда нужно делить исходя из того что нужно получить а если вы будете пытаться как-то ЖопоКостыльно реализовывать чтоб работало общее через одно и тоже место, а разное через разные придёте к реализации bottom left и пр
Ты часом не поклонник ВЮ с ЮВ? Это говорит о том, что минимальный самостоятельный объект у тебя - блок html кода. А разделы это так - для красоты. Дают удобство навигации. Самостоятельной функции они у тебя не несут. Одного я не понял, что тут можно разбить? Код чего? Страничек? У тебя есть Новости, есть Товары. Есть какой-то маленький компонент, - "вывести дерево", - используемый первыми двумя. Все.
сначала не понял даже о чем ты. Хотя если.. Фии! Не, я за Тигипко голосовать буду. Если вообще буду. Они все одинаково противны мне, а Тигипко просто в той же бурсе учился, в которой я сейчас пребываю. Я имел в виду что-то типа общего класса по работе с деревьями, в который буду запихивать настройки (например можно перемещать или нельзя элементы).
Ну, да. Лучше это на JS повесить =) Кстати, вопрос о использовании нескольких модулей на одной странице очень интересный. По-моему, здесь можно клево использовать MVC - в шаблоне теги HTML: [NEWS/LAST] в шаблонизаторе - вызов контроллера LAST модуля NEWS.
ну да, я что-то типа такого использую: HTML: <td id="lCol"> <div id="mainPart">[!object ContentMenu!] 'rootId' : '9', 'includeRoot' : 'false', 'depth' : '1', 'currentId' : 'true', 'depthHighter' : '-1', 'depthLower' : '1', 'templates' : 'modules/content/menu/level-1' [!/object!] <a href="/registration">Регистрация</a> </div> </td> <td id="mCol"> <div id="mainPart">[:mainPart:]</div> </td> <td id="rCol"> [!object newsList!][!/object!] </td>
регулярками. Но сейчас это как говнокостыль. Вот будет время - сделаю нормальный шаблонизатор или возьму h2o
мдя ... я после написания Н-ого количества шаблонизаторов - ушел в смарти (решил что проще для готового метода логику расширять), но потом плюнул - и использую теперь короткие теги для шаблонов ....
все становиться просто когда AJAX дергает модуть/метод в нужное место. а так...по URL надо подцепить шаблон, а там разобраться что куда вставлять. т.е. грубо диспетчер должен знать по урлу куда что. а вот самому модулю пох куда что. он должен контент отдать и забыть.
да, по ajax все проще. Мы можем не инициализировывать главный шаблон а только выдавать нужные данные. Но не всегда ajax применим.
много думал ... в общем не вижу разницы .... 1.есть база (контент|страничка) (может расширятся типом контента) 2.к страничке привязан шаблон 3.шаблон содержит в себе вызовы блоков ... вот эти вызовы могут быть аяксовыми,могут - встроенными ... "все становиться просто когда AJAX дергает модуть/метод в нужное место." - не понял, все равно же шаблон содержит и вызовы Аякса и посадочные места для результатов вызов ..
Не. JS делает запрос и получает html-код, который пихает в нужное место стараницы. JS может полностью генерить всю страницу. Вот когда js определяет, где должно что лежать - это нормально, а когда php - плохо? :???: