LokiDi L0ck

Элементы и классы О_о people2010 Покажите, пожалуйста, а как создаются экземпляры класса window (document)?

s0rr0w Поясняю: в контексте решения товарища MximuS'а (при обращении к файловым функциям php). Молодец!

MximuS Много телодвижений. Короче через file_put_contents.

Поднимаю старую тему, но уже с решением благодаря php 5.3 <?php class Core_Test_Parent { public static function getClassName() { return get_called_class(); } } class Core_Test_Child extends Core_Test_Parent {} echo Core_Test_Child::getClassName(); //Core_Test_Child ?> Теперь вы можете этого хотеть

$idList = array(); foreach ($order->products as $product) { $idList[] = $product->id; } print_r($idList); Не верю.

DOMDocument

$foo = array(5, 10, 20); echo $foo[rand(0,2)];

С данными обычно работают модели, а не контроллеры. В данном контексте стоило бы обратиться к помощникам вида.

Обращайтесь лучше на специализированный форум: http://zendframework.ru/forum/ У вас явно хромает архитектура приложения (подобные вещи должны решаться по-другому).

Bolmazov, создайте наследуемый класс с прописанной в нём кодировке

Работает аналогично, вы так говорите лишь от временного отсутствия опыта. Не только. При приведении к строке, например: (string) $greatRush

Great Rash, не делайте из мухи слона. class User { protected $_name; public function __construct($name) { $this->_name = $name; } public function __toString() { return $this->_name; } } $greatRush = new User('Great Rush'); echo $greatRush; //И это вся суть метода __toString() .toString()

В контексте нашего вопроса: да "обычный", но при этом не выполняющий предъявляемые к другим обычным пользователям требования. Банальное лицемерие. Всё верно. Здесь не та ситуация. И чтобы это понять не надо иметь 7 пядей во лбу.

Искренне надеюсь, что все понимают важную роль модератора в существовании и развитии форума. Их адекватное поведение, скорая (профессиональная) помощь и отзывчивость может привлекать новых людей и делать форум действительно полезным. Ни в коем случае не выступаю против кого бы то ни было и не пытаюсь очернить. Возникший вопрос возник лишь из простого интереса: понимают ли это сами модераторы? Яркий пример: Динамическая структура сайта на основе БД Когда тема интересна, то иногда сам в ней участвую, стараясь оставаться в рамках темы. Каждый из вас их создавал и каждый наверняка знает, что он ожидал помощи, а не воды (или троллинга). Подобного можно ожидать от обычных "пользователей" (что естественно должно контролироваться управляющими форумом людьми), но никак не от модераторов, являющимися костяком форума. У автора возникла проблема при использовании "архитектуры" (или назовите как вам удобнее), решающей его задачи. Как поведение модератора вписывается в название темы (название которой не "Нужен ли мне zf?")? Почему нельзя было проигнорировать вопрос темы, если нет достойного модератора ответа? Вы сами наверняка понимаете, что для автора - это провоцирование и ладно бы от пользователя, но от модератора? Как вы сами думаете, нужен был бы вам такой ответ? Он действительно информационный? Будет ли подобное отношение привлекать людей на форум и делать его полезным? Каждый поймёт, что нет - это очевидно. Безответственный, не понимающий своей роли модератор - рак форума. Но ещё хуже, когда его не лечат.

Нельзя. Выглядит лучше чем script.php?param1=value1&param2=value2. В вашем случае роутер не обязателен. Не надо плодить лишние сущности (для которых понадобится дополнительная память) лишь ради незначительного укорачивания url. Для понимания эффективного использования zf нужно время. К примеру у меня для отображения статических страниц используется всего один роутер.

Нельзя. Маршрутизация определяет какой контроллер должен быть запущен и выполняется только один раз перед диспетчеризацией (читать последний абзац). Не обязательно самому создавать объект Zend_Controller_Router_Rewrite. Его можно получить из фронт контроллера. $router = $frontController->getRouter(); $router->addRoute('tree', new Zend_Controller_Router_Route(':module/:controller/:action/:article/:type')); Все маршруты должны загружаться перед диспетчеризацией. Можете закэшировать их.

Использование маршрутизаторов

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

LunatiK Желание высказанное самим субъектом - совсем не показатель. p.s. в теме не заинтересован, проходил мимо.

LunatiK Есть более тонкие причины боязни OpenSource. Например уважаемый keltanas открывает сообществу исходники для ознакомления (так называемой ) CMF, а оно, ознакомившись, отварачивается к прежним решениям, сочтя это кустарщиной =)

Спасибо, смеялся.

Для более лучшего понимания, приведу пример на ОС. Первый вариант установки модуля соответствует установке приложений в linux (при этом файлы приложения раскидываются по целевым каталогам). Второй вариант - mac os (файлы приложения находятся в одном каталоге), т.е. модуль нашего приложения будет самодостаточен - все свои файлы содержит только в себе.

Предлагаю рассмотреть вопрос тем, кто знаком с zf. Всё нижеописанное лишь размышления на тему. Имеем структуру по умолчанию: <project name>/ application/ configs/ controllers/ helpers/ models/ modules/ views/ filters/ helpers/ scripts/ Bootstrap.php data/ database/ cache/ indexes/ locales/ application/ en_US.mo logs/ sessions/ uploads/ docs/ library/ public/ css/ js/ images/ .htaccess index.php scripts/ jobs/ build/ temp/ tests/ - Введение: 1.1 Каталог "application/" содержит файлы приложения, реализующие mvc. 1.2 Каталог "data/database" может содержать .sql файлы, необходимые для установки/обновления приложения. 1.3 Каталог "data/locales" содержит файлы переводов для приложения. 1.4 Каталог "public" содержит файлы доступные клиенту. В "public/js" соответственно должны располагаться js-скрипты приложения, в "public/css" - стили, и т.д. Теперь представим, что мы решили установить модуль "user" (будет размещён в "application/modules/user") и у которого тоже имеются свои .sql, .mo, .js, .css файлы, расположенные например так: user/ controllers/ models/ views/ data/ database/ user.sql locales/ en_US.mo public/ js/ css/ Теперь есть два варианта развития. I. Согласно пунктам 1.1 и 1.4, файлы из "user/data" должны будут быть разбросаны по соответствующим каталогам приложения. Т.е. после установки модуля, структура приложения будет выглядить например так: <project name>/ application/ ... modules/ user/ /** Каталога "data" больше не существует */ data/ ... database/ module.user.sql locales/ application/ en_US.mo user/ en_US.mo docs/ library/ public/ css/ module.user/ js/ module.user/ II. Оставить каталог "user/data" как он есть (без перемещения файлов). В итоге, модуль после установки будет пользоваться именно им. Вопрос, какой вариант на ваш взгляд смотрится более "логично", почему? p.s. Если остались какие-то вопросы, пожалуйста задавайте. Всё будет уточнено. p.p.s. просьба к модераторам - чистить флейм не по теме. Заранее спасибо.

Пылесос http://dev.mysql.com/tech-resources/articl...hical-data.html

Fenix Теперь Вы мой кумир. Описать архитектуру в паре предложений - это гениально!