Ну подобных расширений в общем-то много довольно. Напрягает то, что довольно громоздки они, для меня многовато лишнего функционала там. Но, возможно, придется заюзать, если более простого решения не найду.
А вообще такое хранение дерева не очень продуктивно (мягко говоря) с точки зрения производительности операций чтения.
Для более лучших сопособов хранения деревьев обратите внимание на materialized path или nested sets - с помщью них можно выбрать все дерево потомков без рекурсии и всего за один запросов..
Если что-то вызывает вопросы в коде, спрашивайте, попробую объяснить, для меня просто каждая строка выглядит банально, по этому не могу себя заставить это комментировать. Аргументы и принцип работы приведенных функций можно прочитать на php.net
@Lomoson: если вы получили error => 0, и tmp_name => /var/www/app/tmp/phpG63n68
значит файл из формы PHP все-таки загрузил во временную директорию при обработке запроса.
В противном случае в поле error - содержался бы код ошибки.
@nobodynoone глупая отмазка для неиспользования форм-билдеров в шаблонах - во всех приличных фреймворках, что я видел форм-билдеры умеют выводить формы а-ля twitter bootstrap - т.е. с враперами полей, метками и все, что душе угодно. Плюс имеют гибкий функционал по добавлению классов, атриботов и т.п. к полям. Уж тут как-раз таки и легче будет менять дизайн, чем когда у вас тонны html-кода.
@PsychoMakaron ну как я написал и как ниже уже отменили - разработчики пишут код на чем им удобно и пользуются теми инструментами, которые удобны и решают их задачи. В любой здравой компании будет именно так - кому-то удобно писать в vim или emacs, кому-то полноценные IDE.
Если судить по тегам, вас интересует веб и PHP. Наиболее часто встречал команды преимущественно с PHPStorm, реже NetBeans. Но есть и кто в SublimeText работают и вполне ок.
Самое простое, что вижу - простой php-скрипт:
/item.php?id=12345
т.е. получаете id товара, лезете за ним в БД и выводите инфу на страницу.
плюс как говорил, нужные еще страницы каталога. Если товары разбиты по категориям то можно сделать скрипт типа:
/catalog.php?category_id=123
лезете в БД и выводите список ссылок на страницы товаров.
учитывая, что товаров много, можно сделать простую пагинрацию (пред. след.)
если сами в php не разумеете, наймите на фрилансе, такая работа не дорого должна стоить.
вот-вот, до открывающего тега <?php не должно быть никакого вывода в браузер - иначе вы не сможете отправить заголовки, коими и являются куки.
Логично же, что сначала шлем заголовки ответа, потом тело
@pavel_salauyou может быть, пример у меня не самый удачный.
Но у меня в PaymentFactory::getManager() не логика проведения платежа – а именно логика определения класса, который должен выполнить платеж, в зависимости от контекста. На реализацию платежа фабрика тут никак не влияет, просто предоставляет нужный класс.
@pavel_salauyou не совсем согласен, я описал именно фабрику в своем примере. Менеджеры платежей именно являются однотипными объектами. Просто по смыслу в данном примере можно было бы применить и шаблон Статегрия, но выглядело бы уже так:
class Order {
protected $manager;
public function __construct(PaymentManager $manager)
{
$this->manager = $manager;
}
public function processPayment($data) {
$this->manager->process($data);
}
}
abstract class PaymentManager
{
abstract public function process($data);
}
class FirstManager extends PaymentManager
{
// ...
}
class SecondManager extends PaymentManager
{
// ...
}
// ....
if($total < 10000) {
$manager = new SecondManager();
}
else {
$manager = new FirstManager();
}
$order = new Order($manager);
$order->processPayment($data);
Это уже чистой воды Strategy – мы подменяем логику работы, заменяя класс. А суть фабрики – просто выдать объект (или иногда класс) определенного типа. Не всегда один тип означает один класс, чаще наоборот. Разная или одинаковая логика в этих классах фабрику уже не заботит.
