Как проинитить данные класса из сериализированного представления объекта?

[dimagolov]

xintrea, вот видишь сколько геморроя ты получил пытаясь сохранять состояние веб-приложения?

я тебе больше скажу, ты, похоже, не задумывался, что один и тот же клиент может одновременно быть на 2-х и более совершенно разных страницах и состояние и набор объектов в каждом случае будут разные. что выйдет при твоей сериализации пояснять нужно дальше, или сам поймешь, что это глупая идея?

 

[xintrea]

Автор оригинала: john.brown

class Decorator extends Controller {
    ....
}
class Menu extends Decorator {}

А что должно быть в Decorator при вот таком наследовании? Походу, мой декоратор со следующийм кодом не подходит

 private $instance = NULL;

 public function __construct()
 {
  parent::Controller();

  $stack=new Stack();
  $objectdata=$stack->get_objectdata();

  if($objectdata!=NULL) $this->instance=unserialize($objectdata);
  else
   {
    $controller_name=__CLASS__.'Controller';
    $cmnd='$this->instance=new '.$controller_name.';';
    eval($cmnd);
   }

 }

 function __call($method, $arguments)
 {
  echo 'Run method '.$method.' with argument '.print_r($arguments, true);
  call_user_func_array(array($this->instance, $method), $arguments);
 }

-~{}~ 03.11.09 19:09:

Автор оригинала: dimagolov
xintrea, вот видишь сколько геморроя ты получил пытаясь сохранять состояние веб-приложения?

я тебе больше скажу, ты, похоже, не задумывался, что один и тот же клиент может одновременно быть на 2-х и более совершенно разных страницах и состояние и набор объектов в каждом случае будут разные. что выйдет при твоей сериализации пояснять нужно дальше, или сам поймешь, что это глупая идея?

Я же не просто так использую свою схему. Я ее использую только внутри страницы администрирования сайта. Администратор полюбому делает в одно время одно действие. И это уже будут его проблемы, если он вдруг откроет две консоли администрирования и начнет одновременно в разных местах что-то менять. От такого и в обычной схеме глюки полезут.

 

[john.brown]

И как выражаеться "неподходит"?

Но лучше послушай, что тебе говорят - и в этом топике, и в другом. Не надо так делать. Данных, которые надо сохранять между вызовами не так много, сессия вполне справится, ничего, кроме геммороя, такой подход не даст...

 

[xintrea]

Автор оригинала: john.brown

class Decorator extends Controller {
    ....
}
class Menu extends Decorator {}

Да, в таком декораторе каким-то образом нужно будет знать тип восстанавливаемого объекта, чтобы если сериализованных данных нет, сделать пустой объект через new. Как это разрулить?

-~{}~ 03.11.09 19:34:

Автор оригинала: john.brown
Но лучше послушай, что тебе говорят - и в этом топике, и в другом. Не надо так делать. Данных, которые надо сохранять между вызовами не так много, сессия вполне справится, ничего, кроме геммороя, такой подход не даст...

Проблема сейчас только в одном - по непонятной причине, в PHP класс может запомнить через сериализацию собственное состояние с помощью serialize($this). А вот обратное действие - восстановить свое состояние из сериализованных данных - сделать не может. Я честногря такой подставы не ожидал.

 

[john.brown]

Изучи с начало мануал по ооп, а потом ужо чудо систему придумывай

get_class($this);

 

[dimagolov]

Я ее использую только внутри страницы администрирования сайта.

начали с "универсального" решения, потом поняли, что решение имеет много ограничений, но продолжаем жрать кактус и пытаться притулить его хоть куда-то, где долбанутость решения не валит все сразу, а только при определенных обстоятельствах.

хозяин барин, конечно, нравиться жрать кактус, жрите...

 

[xintrea]

Автор оригинала: dimagolov
начали с "универсального" решения, потом поняли, что решение имеет много ограничений, но продолжаем жрать кактус и пытаться притулить его хоть куда-то, где долбанутость решения не валит все сразу, а только при определенных обстоятельствах.

Я это понял уже очень давно, поэтому сайты делаю так, что фронтэнд и бакэнд вообще никак не связаны. Для фронтэнда это решение не подходит. А для бакэнда с применением стек-машины очень даже подходит.

 

[dimagolov]

и главное. логика таких "пре-инициализированных" объектов обычно в том, что это дешевле обходится, чем полная инициализация из БД. но это имеет смысл только при массовом использовании подобного во всех запросах, чтобы архитектурный секс (фактически это кеш объектов) компенсировался хотя-бы снижением нагрузки и повышением масштабируемости. но нет, идея выродилась до секса ради секса с исключительно негативными последствиями при пренебрежительно малых положительных.

-~{}~ 03.11.09 12:52:

фронтэнд и бакэнд вообще никак не связаны

извини, а что есть "фронтэнд" и "бакэнд" в твоей терминологии?

-~{}~ 03.11.09 12:56:

Я это понял уже очень давно

целую неделю назад? или прямо тогда-же, когда 10 дней назад тебе сказали "хотите вы странного", ты все понял и начал "делать так, что фронтэнд и бакэнд вообще никак не связаны"?

 

[xintrea]

Автор оригинала: john.brown
Изучи с начало мануал по ооп, а потом ужо чудо систему придумывай
get_class($this);

Я вот не понимаю, в декораторе заполняется $this->instance.

Затем контроллер наследуется от декоратора. Но ведь $this контроллера - это не тоже самое, что $this->instance. Поэтому контроллер будет не заполнен данными.

Воспрос - как можно унаследоваться от декоратора, который заполнил $this->instance так, чтоб оказался заполнен сам объект (т.е. $this) ?

 

[john.brown]

Пошли по второму кругу?

Ответ - никак. $this заменить нельза.

Если тебе неподходит вариант__call(), и не хочеш в ручную писать вызовы делегирования, то увы... такова селява... Придеться тебе отказаться от этой замечательной идеи

 

[xintrea]

В крайнем случае можно отказаться от полной сериализации объектов, и сериализовать только свойства. Конечно, не то что хотелось, но хоть что-то.

-~{}~ 03.11.09 20:43:

Автор оригинала: john.brown
Пошли по второму кругу?
Ответ - никак. $this заменить нельза.

Только непонял, нахрена ты предлагал схему

class Decorator extends Controller {}
class Menu extends Decorator {}

если она принципиально для данной задачи не работает?

 

[john.brown]

Ааааа!
Я тебе это предлагал вместо этого извращения

class Menu extends Controller
{
include(decorator.php);
}

 

[xintrea]

В общем, таки получилось.

Теперь можно работать в трушном ООП-стиле, все прозрачно сохраняется/восстанавливается, о сессиях не думаешь.

На пробу щас сделал счетчик обращений с начала сессии к странице меню. Контроллер меню со счетчиком выглядит так:

Class Menu extends RestoreController
{

 var $menu_counter=0;

 function index()
 {
  // Главная страница администрирования с меню
  $data['content']=$this->adminmenu->get_menu();
  $data['page_counter']=$this->menu_counter++;

  $this->load->view('admin/master_template',$data);
 }
}

То есть, никаких обращений к левым объектам, просто объявляется свойство и используется.

Обновляю свой URL

http://localhost/ci/index.php/admin/menu/index

и счетчик сам крутится.

 

[grigori]

да, аспекты на PHP - это всегда весело