Сейчас веб-проекты обладают достаточно сложной логикой и постоянно меняются, а разрабатывать их нужно быстро. Код должен быть элементарным для чтения и писаться просто, иначе не успеете никуда. А это значит, что в ход идут большиииие такие ООП библиотеки для работы с БД, примитивная модель MVC обрастает большой обвязкой, и всё для того, чтобы выдачу страницу пользователю можно было описать в несколько строчек. Если здесь не использовать эксепшены, то код будет просто длиннее в ненужном месте.
Такой веб-проект у вас в принципе летать не будет, и использование эксепшенов в скорости работы играет далеко не первую роль. Но это и не нужно. Нужна производительность программистов.
И если в таких проектах использовать дедовские методы тюнинга производительности вроде хаков, безумных оптимизаций трёх алгоритмов в один и экономии битов и скорости выполнения скрипта, то следующий за вами программист просто не сможет в указанный срок изменить функционал — он должен будет в вашем оптимизированном коде разбираться.
Не всегда нужно остановить выполнение скрипта. Если вызывать _redirect(), который завершается exit()'ом, то, логично, после него уже ничего не выполнится. А если бросить эксепшен, то на уровне выше можно его поймать, запомнить, что нужен редирект, провести уборку/записать логи/итд, и вот тогда уже завершить работу, выплюнув нужные заголовки.
Тогда, если будете писать статью, объясните в ней, пожалуйста, почему Typo3. Получается, что для того, чтобы сделать простой сайт, нужно потратить два месяца, изучая фактически новый язык, который в будущем пригодится только с Typo3. А для того, чтобы разобраться в существующем проекте и сделать в нём минимальные изменения, сколько потребуется мануалы курить? Полгода, больше?
Помню, когда я изучал Typo3, я был настроен очень серьёзно и полностью проникся строками, написанными в документации: «вы не изучите Typo3 за две недели, вы потратите несколько месяцев, зато потом я вся твоя». Я терпеливо изучал доки, мануалы, сайт в итоге заработал, но чёрт… лучше бы я от руки его тогда написал. Всё, что я узнал для себя нового — это тот самый Typoscript, который мне больше никогда не пригодится. А когда мы передали работу над сайтом студии N, которая специализируется на Typo3, мне прищлось ещё и специалиста оттуда консультировать, нормально?
Видимо, всё-таки, чтобы пользоваться Typo3, нужно по мистическим причинам очень сильно этого хотеть. Мне кажется, что продукт, которым ты пользуешься, должен не только предоставлять тебе функционал, но и делать это таким способом, чтобы в других проектах, где этого продукта не будет никогда, твои наработки можно было использовать, ну или знания хотя бы, опыт. Вот расскажите, какие популярные нынче паттерны проектирования Typo3 помогает узнать новичкам, для которых Вы хотите написать статью?
Собственно, автору спасибо за серию статей. Если даже что-то притянуто за уши (а я не сомневаюсь, что большая часть — правда), то материал всё равно полезный. Есть предметы с гармоничными пропорциями, а есть такие, на которые смотреть вредно. Недавно здесь пролетала статья про типографику в дизайне, про необходимость соблюдать сетку в расчётах отступов при вёрстке — это всё о том же. И хорошо, что прочитав статью, кто-то будет хотя бы задумываться о том, выглядит его дизайн органично или нет.
Кстати, уверен, что в художественных/дизайнерских школах учат соблюдать такие пропорции на подсознательном уровне, так что не удивительно, что у заслуженных дизайнеров они «случайно» обнаруживаются :)
>> А добавьте пример хоть одну рабочую ссылку дерева?
> Внизу статьи ссылка на рабочий пример. Возможно хостинг тупит — попробуйте обновить страницу пару раз.
Упс, там должно было быть написано «добавьте В пример». Чтобы хоть одна ссылка в дереве вела на обновление страницы.
А про куку, проморгал :-/ Чёрт, давно говорю себе: «иди спать, иди спать, иди спать...» :)
* третий диск вставить некуда;
* винт не мёртвый, но подозрения вызывает, хотя и работает.
Так что описываемый метод вполне может быть реальным решением, и нужно быть готовым к нюансам, которые могут возникнуть (пункт 4). А со всем написанным в Ваших комментариях я согласен, разумеется.
Серийник я узнать могу, выкинуть из зеркала тоже, но диск системный, если я выкину из зеркала один, а инжнер в ДЦ физически вытащит другой — хотсвоп не получится. Посмотреть же серийник на винте, который запечатан в корзину — ну я не знаю, телепатически? :)
Хотя я, конечно, согласен, что если точно известно, какой серийник куда в сервер физически воткнут, то остановить перед вытаскиванием его нужно. Сейчас добавлю в пост.
Не очень интуитивно тогда получается — вроде при наведении раздел подсвечивается, но при клике ничего не происходит: ни раскрытия дерева, ни перехода по ссылке, ни подгрузки контента (с раскрытием дерева).
А добавьте пример хоть одну рабочую ссылку дерева?
По поводу сохранения состояния дерева — Вы можете по клику или по onUnload записать состояние дерева в куку, а на следующей странице его прочитать. Не знаю, насколько это best practice, но работать будет.
Сейчас веб-проекты обладают достаточно сложной логикой и постоянно меняются, а разрабатывать их нужно быстро. Код должен быть элементарным для чтения и писаться просто, иначе не успеете никуда. А это значит, что в ход идут большиииие такие ООП библиотеки для работы с БД, примитивная модель MVC обрастает большой обвязкой, и всё для того, чтобы выдачу страницу пользователю можно было описать в несколько строчек. Если здесь не использовать эксепшены, то код будет просто длиннее в ненужном месте.
Такой веб-проект у вас в принципе летать не будет, и использование эксепшенов в скорости работы играет далеко не первую роль. Но это и не нужно. Нужна производительность программистов.
И если в таких проектах использовать дедовские методы тюнинга производительности вроде хаков, безумных оптимизаций трёх алгоритмов в один и экономии битов и скорости выполнения скрипта, то следующий за вами программист просто не сможет в указанный срок изменить функционал — он должен будет в вашем оптимизированном коде разбираться.
Собственно, холиварничать не собирался, просто было интересно Ваше мнение. Спасибо.
Помню, когда я изучал Typo3, я был настроен очень серьёзно и полностью проникся строками, написанными в документации: «вы не изучите Typo3 за две недели, вы потратите несколько месяцев, зато потом я вся твоя». Я терпеливо изучал доки, мануалы, сайт в итоге заработал, но чёрт… лучше бы я от руки его тогда написал. Всё, что я узнал для себя нового — это тот самый Typoscript, который мне больше никогда не пригодится. А когда мы передали работу над сайтом студии N, которая специализируется на Typo3, мне прищлось ещё и специалиста оттуда консультировать, нормально?
Видимо, всё-таки, чтобы пользоваться Typo3, нужно по мистическим причинам очень сильно этого хотеть. Мне кажется, что продукт, которым ты пользуешься, должен не только предоставлять тебе функционал, но и делать это таким способом, чтобы в других проектах, где этого продукта не будет никогда, твои наработки можно было использовать, ну или знания хотя бы, опыт. Вот расскажите, какие популярные нынче паттерны проектирования Typo3 помогает узнать новичкам, для которых Вы хотите написать статью?
Собственно, автору спасибо за серию статей. Если даже что-то притянуто за уши (а я не сомневаюсь, что большая часть — правда), то материал всё равно полезный. Есть предметы с гармоничными пропорциями, а есть такие, на которые смотреть вредно. Недавно здесь пролетала статья про типографику в дизайне, про необходимость соблюдать сетку в расчётах отступов при вёрстке — это всё о том же. И хорошо, что прочитав статью, кто-то будет хотя бы задумываться о том, выглядит его дизайн органично или нет.
Кстати, уверен, что в художественных/дизайнерских школах учат соблюдать такие пропорции на подсознательном уровне, так что не удивительно, что у заслуженных дизайнеров они «случайно» обнаруживаются :)
> Внизу статьи ссылка на рабочий пример. Возможно хостинг тупит — попробуйте обновить страницу пару раз.
Упс, там должно было быть написано «добавьте В пример». Чтобы хоть одна ссылка в дереве вела на обновление страницы.
А про куку, проморгал :-/ Чёрт, давно говорю себе: «иди спать, иди спать, иди спать...» :)
* третий диск вставить некуда;
* винт не мёртвый, но подозрения вызывает, хотя и работает.
Так что описываемый метод вполне может быть реальным решением, и нужно быть готовым к нюансам, которые могут возникнуть (пункт 4). А со всем написанным в Ваших комментариях я согласен, разумеется.
Хотя я, конечно, согласен, что если точно известно, какой серийник куда в сервер физически воткнут, то остановить перед вытаскиванием его нужно. Сейчас добавлю в пост.
По поводу сохранения состояния дерева — Вы можете по клику или по onUnload записать состояние дерева в куку, а на следующей странице его прочитать. Не знаю, насколько это best practice, но работать будет.
Флешке прописывается <param name="wmode" value="transparent" />, и поверх неё можно позиционировать что угодно.
Другое дело, что кнопка в ролике — это не всегда весь ролик целиком, и не всегда эта кнопка неподвижна.