а открывать как мне кажется ничего не надо, мы и так окутаны сетью везде, телефон всегда с тобой всегда в сети, на работе все валится (все уведомления) на почту :) т.е. как бы да есть такая возможность, но ведь следует видимо согласится что ежедневник то и пытаться напоминать не будет :)
Я не берусь оценивать справедливость высказонных идей какой-либо из сторон, однако хочется отметить, что
сравнение автора данного поста гаджетов (из-за которых мы якобы становимся тупее) с ежедневником не со всем корректно. Потому как ежедневник не напомнит сам, и записанное в него надо еще вспомнить посмотреть/открыть. Вы же можете банально не открыть сегодня ежедневник. Электронные же гаджеты лишены этого недостатка :)
define(«APP_PATH», __DIR__. DS. '..'. DS. 'app'. DS);
set_include_path(APP_PATH); // adding new path to include_path
spl_autoload_extensions(".php"); // comma-separated list
spl_autoload_register();
только вот эту мелочь стоит гда нить ранее объявить
spl_autoload_extensions(".php"); // comma-separated list
spl_autoload_register();
но вот посмотришь на код глубже и порой от такого количества обратных слешей иногда берет дрожжжж :)
но это больше проблема namespace'ов нежли способа загрузки файлов :)
А еще лучше начать использовать namespace'ы с автомотической загрузкой классов и тогда в этом плане наступит полная эйфория :). Хотя я сам и пользуюсь этим способом, код от этого лучше выглядеть не начинает :( вместо конструкции require*/include* появляется обратный слеш :(
Однако, для проведения XSS этого и не требуется. Используя в качестве параметра $theme значение ../redirect.php?url=http://evilsite.domain/evilstylesheet
но ведь в этом случае надо что б на атакуемом сервере был такой файл (redirect.php) или я чего то не допонимаю?
Я когда решал подобную задачу выяснил что:
— OO кушает много ресурсов, даже когда запущен без GUI
— он действительно может подвиснуть
— у OO есть интерфейс UNО который в теории очень хорош, ОО на одном сервере твой клиент на другом и с помощью UNO можно проводить любые манипуляции с документом. Но для php есть одно расширение, заставить все это вместе работать это просто подвиг :), документация по всему этому очень не простая мягко говоря.
Все это привело меня к тому что данное решение если и имеет право на жизнь то ни как для массовой обработки постоянных запросов.
Но я согласен с автором что наиболее верный способ (с наименьшим кол-вом притензий к полученному документу это виртуальный принтер). Поставить таковой под линукс нечего делать. Вот только найти нормальный софт который может открыть и отправить на печать желаемый файл без ГУЯ, да и с ним тоже, это проблема :(
на мой взгляд да человек «спроектирован» таким образом что ему не нужны ни очки ни зубная щетка, но жизнидеятельность априори дальнозоркого человека приводит к тому что он бОльшую часть жизни смотрет перед собой а не в даль и по этому ему нужны за частую очки в раннем возрасте (я не учитываю врожденные дефекты), так то и с зубами, именно употребляю ту гадость которой нас кормит и приводит к тому что нам вроде бы как бы нужно чистить зубы а потом выясняется что и не порошком, и не просто пастой а щеткой да еще и автоматической а нет ультразвуком сейчас модно и понеслоь… не ужели вы думаете что мы «спроектированы» быть такими? а много вы знаете хорошо работающих ваших программ спроектированных для одной задачи, но используемых соверешено иначе?
многие считают что эти щетки приносят больше вреда чем пользы
Электрическая зубная щетка с круглой движущейся головкой, совершающая полукруговые движения «Braun Oral-B» — это самая коварная щетка, которую только смогли придумать! www.passion.ru/pasya/s.php/6196.htm
сравнение автора данного поста гаджетов (из-за которых мы якобы становимся тупее) с ежедневником не со всем корректно. Потому как ежедневник не напомнит сам, и записанное в него надо еще вспомнить посмотреть/открыть. Вы же можете банально не открыть сегодня ежедневник. Электронные же гаджеты лишены этого недостатка :)
т.е. все полностью упирается в вашу архитектуру, в некоторых уже готовых приложениях лучше убиться чем начинать использовать namespace'ы.
Если же вы делаете все с нуля то нет причин не использовать разумный подход, и лучше планировать свою архитектуру.
define(«APP_PATH», __DIR__. DS. '..'. DS. 'app'. DS);
set_include_path(APP_PATH); // adding new path to include_path
spl_autoload_extensions(".php"); // comma-separated list
spl_autoload_register();
вот теперь все выглядит как надо.
только вот эту мелочь стоит гда нить ранее объявить
spl_autoload_extensions(".php"); // comma-separated list
spl_autoload_register();
но вот посмотришь на код глубже и порой от такого количества обратных слешей иногда берет дрожжжж :)
но это больше проблема namespace'ов нежли способа загрузки файлов :)
Однако, для проведения XSS этого и не требуется. Используя в качестве параметра $theme значение ../redirect.php?url=http://evilsite.domain/evilstylesheet
но ведь в этом случае надо что б на атакуемом сервере был такой файл (redirect.php) или я чего то не допонимаю?
если так то до каких пор? это ограничение со временем снимаеттся или как?
— OO кушает много ресурсов, даже когда запущен без GUI
— он действительно может подвиснуть
— у OO есть интерфейс UNО который в теории очень хорош, ОО на одном сервере твой клиент на другом и с помощью UNO можно проводить любые манипуляции с документом. Но для php есть одно расширение, заставить все это вместе работать это просто подвиг :), документация по всему этому очень не простая мягко говоря.
Все это привело меня к тому что данное решение если и имеет право на жизнь то ни как для массовой обработки постоянных запросов.
Но я согласен с автором что наиболее верный способ (с наименьшим кол-вом притензий к полученному документу это виртуальный принтер). Поставить таковой под линукс нечего делать. Вот только найти нормальный софт который может открыть и отправить на печать желаемый файл без ГУЯ, да и с ним тоже, это проблема :(
Электрическая зубная щетка с круглой движущейся головкой, совершающая полукруговые движения «Braun Oral-B» — это самая коварная щетка, которую только смогли придумать!
www.passion.ru/pasya/s.php/6196.htm