Frameworks. frameworks, frameworks(+)

[atv]

Есть такие в которых учтена?

Есть.

Вы знаете как исправить там, где не учтена?

Где не учтена, там не исправиш, нужно закладывать с самого нчала.

Посмотрите в сторону событийно-ориентированных фрэймворков. Они ещё недостаточно хорошо реализованы, но события сами по себе это выход из положения.

Более конкретно сказать не могу, про это целые книги написаны, тот же Гради Буч.

...все равно тяжелы для внедрения -- поскольку либо надо учиться...

А если учесть, что надо ещё научиться программированию, а перед этим освоить компьютер

Не могу не согласиться с [sid]-ом. Программирование это область в которой постоянно нужно учиться, даже в силу того, что программирование всё ещё развивается. Программист никогда не сможет сказать себе "всё, я всё освоил и до пенсии могу не морочить себе голову".

 

[Фантазер]

atv

Мне нравятся Ваши ответы Им даже возразить нельзя при желании.

Сравните:

Где не учтена, там не исправиш, нужно закладывать с самого нчала.


и


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


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


Посмотрите в сторону событийно-ориентированных фрэймворков. Они ещё недостаточно хорошо реализованы, но события сами по себе это выход из положения.


Aspect-Oriented? Ну оно вроде как продолжение практик ООП, что изложены в книжках по паттернам. Т.е. они упрощают жизнь и в тоже время еще более сложны в освоении. На мой взгляд сам по себе подход не решает проблему того, что фреймворк у каждого свой, скорее всего он ее даже усугубит.

И еще есть такой принцип "стреляй и беги" (когда ты стреляешь -- не можешь бежать и наоборот) т.е. выучился ООП паттернам, прочувствовал -- т.е. выстрелил, -- теперь беги -- получи от этого работающее приложение, иначе есть риск до старости смотреть в направлении чего-то нового.

 

[_RVK_]

Посмотрите в сторону событийно-ориентированных фрэймворков. Они ещё недостаточно хорошо реализованы

PRADO?

События, сами по себе реализуются с использованием паттерна Observer (поправте если неправ). Это всего лишь незначительная часть, хоть и достаточно важная. И никакого глобального отличия она сама по себе не предлагает.

 

[Фантазер]

Автор оригинала: _RVK_
PRADO?

События, сами по себе реализуются с использованием паттерна Observer (поправте если неправ). Это всего лишь незначительная часть, хоть и достаточно важная. И никакого глобального отличия она сама по себе не предлагает.

Если имелось в виду именно Event-Driven, -- то полностью согласен с Вашим ответом. Это всего-навсего один из приемов.

 

[atv]

Мне нравятся Ваши ответы Им даже возразить нельзя при желании.

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

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

Мысль единственная - можно создать, так сказать, "идеальный" фрэймворк. Как? - событийно-ориентированные фрэймворки, они же Event-Driven.

Это всего лишь незначительная часть, хоть и достаточно важная.

Это всего-навсего один из приемов.

Ассемблер - это всего навсего один из приёмов по срвнению с машинными кодами. Процедурное программирование - это всего-навсего один из приёмов по сравнению с ассемблером. ОО Прграммирование - это тоже всего-нвсего один из приёмов по организации тех же машинных кодов

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

PRADO:
Довольно-таки неудачная реализация событий. События объектов, в принципе, выполняют свои функции, но реализованы слишком запутанно. Много лишнего кода.

События приложения, можно сказать, отсутсвуют. Они реализованы в виде последовательных шагов, жёстко определённых в классе Application.

Классы силно перегружены - выполняют больше 2-3х ролей.

Им бы исправить модель событий, и было бы ничего.

 

[_RVK_]

atv

Я говорю о том, что наличие или отсутствие механизма событий говорит лишь о том, что данный механизм в ФВ есть. Он не вносит в ФВ кардинальных отличий, какие есть между процедурным и ОО подходом. В ENVOS не реализован паттерн Observer. Но это не означает что когда он будет реализован, это будет уже совершенно другой фреймверк.

 

[Фантазер]

Автор оригинала: atv
Вот именно Ваше желание - возражать, спорить, отстаивать свою точку зрения, а не пытаться понять чужую, прийти к согласию, укрепить или изменить свою точку зрения. Я лишаю Вас этого удовольствия

Ну моя цель выявить закономерность (в данном случае почему все пишут свои фреймворки), высказать соображение, и понять оппонента. Если оппонент отвечает так, что понять его невозможно, ну что ж. Упс. Наверное нет смысла продолжать.

Автор оригинала: atv
Мысль единственная - можно создать, так сказать, "идеальный" фрэймворк. Как? - событийно-ориентированные фрэймворки, они же Event-Driven.

Эту мысль надо угадать, так? Вы этого еще не говорили. Хорошо. От слово можно, до слова сделано очень далеко, и не всегда это очевидно. Вы не объяснили почему этот подход позволит избежать обсуждаемых сложностей. Плюс опять же я уже гворил "Идеальный" не возможен, потому-то у всех принципы разработки на данный текущий момент разные.

Автор оригинала: atv
Простите, что говорю загадками, но в двух словах не объясниш преимущества введения событий, тем более я сам только разбираюсь и эксперементирую.

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

Правильнее будет - "Я думаю их можно делать руководствуясь принципами event-driven потому-то и потому-то" - и будет всем польза -- вы выразите мысль, а собеседник поймет о чем речь.

Спасибо за общение, потому как мне действительно очень давно хотелось поговорить на эту тему.

 

[whirlwind]

>Мысль единственная - можно создать, так сказать, "идеальный" фрэймворк. Как? - событийно-ориентированные фрэймворки, они же Event-Driven.

Вот я раньше то же пытался по принципу ED хотя бы вью реализовать. В результате нескольких попыток получалась целая куча маленьких компонентиков, которые, по сути, образовывали язык в языке. Естественно, что чем из большего количества элементов состоит механизм, тем больше усилий он требует для поддержки его работоспособности. Легко представить, как необходимость дополнительного изучения отразится на интересе со стороны.

Долго я морочился с контроллером MVC, в итоге пошел от модели и получил два итоговых класса контроллера: контроллер формы и списковый контроллер, который использует указанный контроллер формы в качестве базового. Для более быстрой реализации связи контроллера с моделью на основе моего варианта ORM, был произведен наследник контроллера формы, который требует ORM класс для инициализации. В итоге, например контроллер пользователя занимат всего одну страницу редактора

class Form_User extends Form_Persistent {

    public function registerRequisites(){
        if ( ($obj = $this->getPersistentObject()) !== null ) return true;
        $this->setPersistentObject(new User);
        $this->addRequisite("button_del",WCMF_RT_BOOL);
        $this->addRequisite("button_upd",WCMF_RT_BOOL);
        if ( !parent::registerRequisites() ) return false;
        return true;
    }

    public function isInsertMode(){
        return $this->button_upd->getValue() ? true : false;
    }

    public function isDeleteMode(){
        return $this->button_del->getValue() ? true : false;
    }

    public function stagePrepare(){
        if ( !parent::stagePrepare() ) return false;
        $user = $this->getPersistentObject();
		if ( !$user->isNew() ) $this->login->to_model = false;
		$this->registred->to_model = false;
        return true;
    }

    public function stageStore(){
        if ( !parent::stageStore() ) return false;
        $user = $this->getPersistentObject();
		if ( Auth::getCurrentUser()->isUserInGroup("admin")
			&& $user->isSelected() )
			$this->button_del->visible = true;
        return true;
    }
}

Списковый контроллер выглядит ничуть не длиннее. Например для списка пользовательских групп.

class List_Group extends List_Controller {

    public function registerRequisites(){
        if ( ($obj = $this->getBaseController()) !== null ) return true;
		$bc = new Form_Group;
        $this->setBaseController($bc);
        if ( !parent::registerRequisites() ) return false;
		$bc->setFlag("editable",false);
		$bc->setFlag("to_model",false);
		if ( Auth::getCurrentUser()->isUserInGroup("admin") ){
			$bc->enableInputProcessing();
			$bc->description->to_model = true;
			$bc->description->editable = true;
		}else{
			$bc->disableInputProcessing();
		}
		return true;
    }

    public function stagePrepareOutput(){
        if ( !parent::stagePrepareOutput() ) return false;
        $obj = $this->getBaseController()->getPersistentObject(true);
        return $obj->selectObjects();
    }

    public function setupEnumeratingCriteria(){
        if ( !parent::setupEnumeratingCriteria() ) return false;
        $obj = $this->getBaseController()->getPersistentObject(true);
        $obj->resetFilter();
        return $obj->orderBy("id");
    }

    public function nextModelElement(){
		if ( $this->getBaseController()->getPersistentObject()->next() )
			return $this->getBaseController()->toForm();
		return false;
    }

}

При всем этом получилась очень даже хорошая и прозрачная схема:

1. Логика отдельного объекта сосредоточена в отденом классе (которые по сути наследники одного единственного класса ORM). Никакой пользователь этого класса, не может нарушить логику работы этого объекта путем каких-либо вызовов или установки каких-либо параметров.
2. Логика поведения контроллера может быть завязана на классах ORM и может использовать устойчивые объекты в своей работе, но это не является обязательным условием. Основная задача контроллера - трансляция ввода из формы в модель, а после применения введенных изменений, трансляция вывода из модели в форму. Но самый смак контроллеров, то что их можно использовать несколько в пределах одного сеанса, и можно использовать контроллеры внутри контроллеров, в зависимости от алгоритма. При чем, снаружи контроллеры легко управляются, т.к. большинство методов являются публичными. Любые этапы работы могут быть вызваны вручную. Ну в общем я к тому что прозрачность и расплывчатость общего восприятия, которые непременно будут сопровождать любые тесносвязанные компоненты или же ED модели, они являются отталкивающим фактором.

И на последок приведу маленький примерчик, как выглядит контроллер профиля пользователя на основе приведенного выше контроллера формы пользователя

class Form_User_Profile extends Form_User {

    public function registerRequisites(){
		if ( !parent::registerRequisites() ) return false;
		$this->login->to_model = false;
		$this->f_active->to_model = false;
		$this->registred->to_model = false;
        return true;
    }

    public function stagePrepare(){
		return $this->setPersistentObject(Auth::getCurrentUser());
    }
}

по моему выглядит неплохо

-~{}~ 16.02.06 13:36:

ЗЫ. Ах да, забыл показать как контроллер выглядит со стороны пользователя класса

$o = new Out_Smarty;
$i = new In_HTTP;
$c = new Form_User_Profile;
$user = Auth::getCurrentUser($o->smarty);
if ( $user->login == "guest" ){
	$template = "no_access.tpl";
}else{
	$c->enableInputProcessing();
	$c->run($i,$o);
	$template = "reference/profile.tpl";
}
$o->smarty->display($template);

 

[Фантазер]

whirlwind

вот -- это примерно то, о чем я говорю -- набор классов с описанием.

Интересно -- я посмотрю еще вечером.

 

[atv]

В ENVOS не реализован паттерн Observer. Но это не означает что когда он будет реализован, это будет уже совершенно другой фреймверк.

Observer - это одна из множества моделей событий и относиться больше к событиям приложения. Существуют ещё события объектов. Введение только одного Observer конечно же ничего кардинально не изменит.

Ну моя цель выявить закономерность (в данном случае почему все пишут свои фреймворки), высказать соображение, и понять оппонента.

ОК. Забираю свои слова обратно.

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

Так то оно так, да только чуточку не так. Ответить легко, а объяснить трудно. Я в курсе принципа, но ещё не в курсе как его складно изложить.

Да, -- детали это целая книжка, но принцип зачастую очень прост...

Ну что я могу сказать. Гради Буч, например, это не детали, это фундамент, это летопись всего развития программирования, это один принцип вытекающий из другого. Как можно объяснить производную человеку, который ещё не освоил арифметику, хотя принцип производной простой.

Простите, я не знаю Вашего уровня, и нисколько не хочу сказать, что он низкий.

...вы выразите мысль, а собеседник поймет о чем речь.

Что ж, если у Вас подход не возражать, а понимать, милости просим

Итак, как говорит Гради Буч, миру присуща сложность. Именно поэтому перед программистами встают такие сложные задачи. Человеку тяжело справляться с этой сложностью в силу ограничений его мозга. Но, люди научились справляться с этой сложностью используя для этого абстракции (так многими нелюбимые). Прошу камнями в меня не кидать за этот абзац. За подробностями обращайтесь к первоисточнику.

Далее, тот же Гради Буч выделяет такую абстракцию как события. В этой статье можно прочитать пару мыслей по поводу событий (http://php.com.ua/ru/articles/other/php_events.htm).
В частности, события там сравниваются с интерфейсом.

Вы согласны с тем, что сторонними библиотеками, такими как PEAR, ADODB и т.д. удобно пользоваться, потому что у них есть вполне определённый интерфейс и Вас не волнует что там происходит внутри, достаточно ознакомиться с интерфейсом.

Так вот, события можно сравнить с выходным интерфейсом, со всеми вытекающими отсюда последствиями. Объект, имеющий события, начинает обладать поведением (лучшего термина пока не нашёл). Появляется возможность повторно использовать поведение объекта, чего небыло раньше. Т.е. в повторно используемый код можно отнести ещё большую часть приложения. Остаётся только реализовать детали - обработчики событий.

Вот изложение "в двух словах", хотя очень многое осталось недосказанным.

-~{}~ 16.02.06 19:15:

Ну в общем я к тому что прозрачность и расплывчатость общего восприятия, которые непременно будут сопровождать любые тесносвязанные компоненты или же ED модели, они являются отталкивающим фактором.

Поэтому в ООП и стремяться снизить взаимосвязанность между компонентами, в разумных пределах, ведь если компоненты не связаны, значит они ничего не делают. ED модели, как раз, позволяют снизить взаимосвязанность.

 

[Sherman]

Кстати человек, который создал PRADO пытался взять кое-что от Microsoft ASP.NET (я говорю не только о названиях методов), по-моему он слизал у них viewstate, например.

Одним из приципов архитектуры ASP.NET(Framework) является событийное программирование, т.к. каждый компонент обладает кучей событий, состояниями и т.д.), но здесь есть серьезные ограничения для php и для HTTP в целом.

1. Сердцем событий являются делегаты. Как мы знаем в php пока с тим проблемы.
2. HTTP не умеет хранить состояния, ms сделали viewstate, но большинство нормальных разработчиков его почти полностью отключает, т.к. гонять сотни килобайт «впустую» довольно накладно(хотя это спорный момент с сегодняшними мощностями каналов), ну и плюс на клиенте это банальный javascript

Еще я в первом посте говорил об автоматизации разработки. Еще раз уточню, я имел ввиду, что крайне важным является для разработчика наличие интегрированных комплексных средств разработки! А это не только framework. Это поддержка быстрого создания пользовательского интерфейса, быстрая конфигурация приложения, быстрое создание инсталяции проекта(deployment) и т.д.

Сейчас частично это присутствует в разных фрейворках разрознено и не поддерживается на уровне IDE(например ZEND).

 

[Фантазер]

atv, теперь понял.

События представляют удобный интерфейс для взаимодействия между компонентами, также, как MVC предоставляет интерфей для взаимодействия между функциональными блоками, более того, не только интерфейс, но и словарь терминов, которые понятны программистам.

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

Так, что соль как всегда в деталях

-~{}~ 17.02.06 10:00:

В деталях -- в смысле насколько красиво будет выглядеть такая реализация.

-~{}~ 17.02.06 10:04:

Sherman,

Кстати быстрая разработка интерфейса совсем не серебрянная пуля -- вспомните борланд билдер и микрософт вижуал си++ -- и ничего -- все писали на микрософт си++, хоть там и не было визуального редактора форм. И Биллдер как-то зачах, сейчас его вроде в пакет дельфей хотят включить.

Да и плюс специфика веб -- форма на клиенте живет независимо от серверного скрипта. Может поэтому все за аякс ухватились, как за волшебную палочку.

 

[_RVK_]

се писали на микрософт си++

Не все

хоть там и не было визуального редактора форм

Был и есть

И Биллдер как-то зачах

Да вроде здравствует

 

[[sid]]

[offtop]
Этот топик зачах три поста назад. Может пора его закрывать? Каждый кажется сделал для себя соответствующие выводы!
[/offtop]

 

[_RVK_]

Вообще ваши рассуждения умиляют. Нужно то, нужно это... развели тут демогогию. Если вы так хорошо понимаете проблемы вебориентированных ФВ, то почему мы до сих пор не увидели идеального ФВ? Слова хорошо, но дело лучше!

 

[[sid]]

_RVK_
А кажется никто и не говорил, что все так просто. Наоборот все довольно сложно (на тему сложности я уже говорил).

Но это только часть проблемы. Вторая часть заключается в том, что это тема околонаучная и сугубо теоретическая и рассуждать на эту тему надо ОЧЕНЬ осторожно, выбросив из лексикона слова: "определенно", "однозначно", "конечно же" etc. Это основная причина, почему я отписал сюда всего два поста.

 

[Фантазер]

_RVK_

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

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

 

[atv]

Простите, я не договорил, занят был.

1. Сердцем событий являются делегаты. Как мы знаем в php пока с тим проблемы.

Кто-то думает что события это Observer, кто-то думает что события это делегаты. В принципе это верно, но это не единственные модели событий. Я уже предлагал в предыдущем топике статью про события. Вы её читали? Похоже что нет.

Еще я в первом посте говорил об автоматизации разработки.

Кстати,я вспомнил проэкт TurboPHP, интересный проэкт, посмотрите, тоже событийно - ориентированный.

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

Дело в том, что форма находиться на уровне приложения, т.е. на более высоком уровне абстракции по сравнению с фрэймворком. Фрэймворк, пытающийся реализовать форму, залазит на чужую территорию. Форма всегда остаётся за конечным разработчиком, поэтому тут они не пересекутся.

Вообще ваши рассуждения умиляют. Нужно то, нужно это... развели тут демогогию. Если вы так хорошо понимаете проблемы вебориентированных ФВ, то почему мы до сих пор не увидели идеального ФВ?

Ну и чего вы надулись Хочеться нам поговорить, на то он и форум.

Слова хорошо, но дело лучше!

Позволю себе заметить, что действия бывают физические, умственные и эмоциональные, причём физические совершаются в последнюю очередь. Вот подумаем и сделаем. Кстати, работа уже давно ведётся, может Вы просто не заметили.

 

[_RVK_]

Кто-то думает что события это Observer, кто-то думает что события это делегаты. В принципе это верно, но это не единственные модели событий.

Может предложешь саою? Или лучше паттерн.

 

[ForJest]

И все же, мало кто задумывался(или я пропустил), почему же навороченные фреймворки на php не пользуются популярностью.

При всём уважении к уже ответившим в данный топик, но может мне кто-то разъяснит
- Что такое "навороченные фреймворки", желательно со ссылками на оные
- И что значит не пользуются популярностью? В чём измеряется популярность и откуда взяты данные для "навороченных фреймворков" (ссылки на которые желательно дать)?