Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 247
Чо-та по описанию напоминает Hop - язычок, который зараз задает поведение на сервере и клиенте.
Нет по идеологии Адепт похож на спецификацию JSF от sun
проект интересный. А как познакомиться с ним можно? (я про сорсы)
Мы сейчас активно доводим код до такого состояния,чтобы его можно было показать людям(php-доки, лицензия и т.д.). Поэтому как доделаем так сразу же и выложим. Ориентировочно к концу февраля.
Вы можете зарегистрироваться у нас и мы будем держать вас в курсе.
Для того, чтобы понять "а оно нам нада?" нужно понять сколько вообще среди "программистов" на PHP есть людей, понимающих хоть что-то в программировании. Способных что-то спроектировать и реализовать, а не просто дёргающих куски кода отовсюду, а потом удивляющихся что у них простейшая страничка 20 секунд грузится.
На Хабрахабре таких людей меньше "средней нормы по индустрии", но достаточно ли их чтобы поддержать ваш фреймворк ? Ему же придётся соревноваться с рельсами и GWT, а не с другими PHP-фреймворками (если судить чисто по описанию). Много ли людей захотят использовать вменяемый фреймворк на невменяемом языке - вот в чём вопрос...
На Хабрахабре таких людей меньше "средней нормы по индустрии", но достаточно ли их чтобы поддержать ваш фреймворк ? Ему же придётся соревноваться с рельсами и GWT, а не с другими PHP-фреймворками (если судить чисто по описанию). Много ли людей захотят использовать вменяемый фреймворк на невменяемом языке - вот в чём вопрос...
Я довольно долго пишу на PHP и считаю его нормальным вменяемым языком(я имею ввиду 5). Вот вменяемых программистов там реально на порядок меньше чем среди других платформ. Но мы надеемся на лучшее :-)
PHP вменяемый язык, но, к сожелению слишком легкий для познания, что и превлекает кучу быдло кодеров, которые считают что ооп следует применять только для каких-то одних мифических целей, паттерны - зло и от лукавого, а написание кода в столбик - самый лучший способ и к тому же быстрый
В то же время по крайней мере мало кто будет спорить что преимущества ООП проявляются только в крупных проектах, постоянно подвергающихся рефакторингу и усложнению функциональности. Применять ООП только ради одного ООП это тоже быдлокодинг.
Не согласен. Здесь скорее повлияет сложность проекта чем его размер.
Прежде чем высказывать компетентное мнение по ООП, попробуйте поработать с ним какое-то время.
Ну и интересно сколько же надо писать на ООП, чтобы иметь право на мнение?
Писать нужно ровно до того момента, когда избавляетесь от чепушиных стереотипов полученных от супер-мега-хацкеров. Типа, ООП нужно применять только на больших проектах. А процедурное программирование на маленьких.
Позвольте спросить, а где тогда применять функциональное, аспектное, прототипное и другие?
Позвольте спросить, а где тогда применять функциональное, аспектное, прототипное и другие?
Отвечаю: любая из технологий применима в случае необходимости и наличия здравой головы и умелых рук. Мы используем комбинации ООП, есть и реализация аспектной библиотеки (не анонсированная, но весьма перспективная).
Избавьтесь, от предрассудков. HTTP не должен вам указывать, как писать, не заостряйте свое внимание на более приятных вещах, чем запрос-ответ.
Избавьтесь, от предрассудков. HTTP не должен вам указывать, как писать, не заостряйте свое внимание на более приятных вещах, чем запрос-ответ.
Нужно просто понять, что существует несколько парадигм программирования, в том числе и полностью объектная и что класс - это не только неймспейс с кучей фунцкий.
писать нужно до просветления ;) ;) ;)
Если вы - профи, то они вам мешают также, как дети на футбольном поле Бекхему.
Стиль изложения - на пять с плюсом, по крайней мере, на мой вкус =) Ловите плюс.
Проект обязательно гляну, но позже..
Проект обязательно гляну, но позже..
Просто JSF, на мой взгляд, является наиболее вменяемой спецификацией для компонент веб-интерфейсов. Не случайно, на ее основе в Java существует более 15 реализаций. Вообще странно, что в php никто пока не осмеливался ранее предложить реализацию JSF, а зря. Потому php и выглядит как язык лапшакодеров, а не людей, способных строить удобные интерфейсы с помощью внятных библиотек и архитектур.
А мне Битрикс напомнило, хотя он и не фреймворк.
Говорила же тебе мама: "Не пиши своих php фреймворков?". Почему ты ее не послушал? Не писал бы, тогда не мучался "может это еще кому-нибудь интересно..."
Вижу, с компонентами у вас все замечательно, а как насчет среды, где бы их можно было быстро вставлять и настраивать? (Типа Delphi) :)
Ключевой фичей проекта является наличие IDE, точнее набора плагинов к Eclipse.
Редактор шаблонов интегрирован с HTML/CSS/JS, подсвечиает, форматирует, валидирует структуру разметки, которая представляет осбой обогащенный HTML. Более не стоит запоминать десятки тегов и атрибутов, пусть среда сама подскажет. Также не стоит тратить время на выравнивание и "прилизывание" кода шаблонов, достаточно нажвать разок Ctrl+Shift+F. Поработав несколько недель, понимаешь, что разработка движеться много быстрее.
Вообще, это нормальная практика хороших инструментов, жаль что Php только начинает обрастать подобными вещами, но прогресс очевиден, ZendFramework+Neon/PDT, а теперь ZendFramework+Neon/PDT + Adept. Кстати, есть возможность снабдить IDE всеми необходимыми мастерами и шаблонами. Долой рутину, товарищи! ;-)
Редактор шаблонов интегрирован с HTML/CSS/JS, подсвечиает, форматирует, валидирует структуру разметки, которая представляет осбой обогащенный HTML. Более не стоит запоминать десятки тегов и атрибутов, пусть среда сама подскажет. Также не стоит тратить время на выравнивание и "прилизывание" кода шаблонов, достаточно нажвать разок Ctrl+Shift+F. Поработав несколько недель, понимаешь, что разработка движеться много быстрее.
Вообще, это нормальная практика хороших инструментов, жаль что Php только начинает обрастать подобными вещами, но прогресс очевиден, ZendFramework+Neon/PDT, а теперь ZendFramework+Neon/PDT + Adept. Кстати, есть возможность снабдить IDE всеми необходимыми мастерами и шаблонами. Долой рутину, товарищи! ;-)
Не знаю, как там внутри, но по описанию похоже на Prado (http://www.pradosoft.com/)
Сравнение c Prado.
С одной стороны, наконец, кто-то не побоялся сказать страшную вещь: "Классические реализации MVC, не лучшим образом подходят для предметной области PHP". Потому что разработаны они изначально для десктопных графических приложений.
С другой, отказавшись от MVC, начали заниматься тем же самым — попыткой подогнать веб-систему под тот же десктоп.
С другой, отказавшись от MVC, начали заниматься тем же самым — попыткой подогнать веб-систему под тот же десктоп.
А что в этом плохого? Мы пытаемся чтобы программист реализовывая web-проект думал о бизнес логике, а не о том, как с верстать HTML, чтобы получилось дерево, и как потом с этой конструкцией работать. Интересно, как бы люди писали GUI приложения, если бы им всегда нужно было вручную отслеживать положение мыши и в ручную заниматься отрисовкой UI компонент?
Вобще-то MVC как раз для того и используется, чтобы программист не верстал HTML.
Верстать должен верстальщик. А сам движок не должен изображать из себя верстальщика — ничего хорошего из этого не выйдет.
Отслеживанием же положения мыши занимается ОС клиента и движок его браузера. Вашего ответа я не понял. Я обратил внимание на то, что вы пытаетесь делать то, что вам не понравилось в MVC.
Создание же страницы из стандартных элементов, со стандартным поведением, это, скорее всего, JS-UI-библиотека, возможно, с некоторой серверной PHP-прослойкой.
То же, что называется "фреймворк", "движок" и т.п. должно работать в другой области — в хранении, преобразовании и выдаче данных, разделении привилегий, отслеживании сеансов, формировании вывода.
У PHP не должно быть никаких кнопок, контроллов и т.п. У него есть запрос, он должен отдать ответ и всё.
Если в этом самом конечном ответе будет задействован тот же JS-UI-немногоPHP-фреймворк, пожалуйста.
Верстать должен верстальщик. А сам движок не должен изображать из себя верстальщика — ничего хорошего из этого не выйдет.
Отслеживанием же положения мыши занимается ОС клиента и движок его браузера. Вашего ответа я не понял. Я обратил внимание на то, что вы пытаетесь делать то, что вам не понравилось в MVC.
Создание же страницы из стандартных элементов, со стандартным поведением, это, скорее всего, JS-UI-библиотека, возможно, с некоторой серверной PHP-прослойкой.
То же, что называется "фреймворк", "движок" и т.п. должно работать в другой области — в хранении, преобразовании и выдаче данных, разделении привилегий, отслеживании сеансов, формировании вывода.
У PHP не должно быть никаких кнопок, контроллов и т.п. У него есть запрос, он должен отдать ответ и всё.
Если в этом самом конечном ответе будет задействован тот же JS-UI-немногоPHP-фреймворк, пожалуйста.
Программист не верстает, он проектирует интерфейс. В компонентно-событйином подходе мы отдаем компонентам валидацию (которую вы, наверняка, каждый раз прикручиваете в своем php модуле), конвертацию данных, и облегчаем жизнь нашему дизайнеру, которому не нужно сто раз выверстывать набальные элементы управления, формы и т.п., а достаточно подправить интерфейс.
Также наши контроллеры, становятся универсальны, когда данные в них передаются компонентами, а не беруться из жесткозакодированных полей запроса. Т.о. один контроллер может кочевать в разные проекты.
Также наши контроллеры, становятся универсальны, когда данные в них передаются компонентами, а не беруться из жесткозакодированных полей запроса. Т.о. один контроллер может кочевать в разные проекты.
Повторное использование кода, это основа основ профессионального программирования. Не думаю, что только вы сумели добиться его с помощью UI-компонент.
Давайте отделим мясные продукты от насекомых. Что вы делаете?
Серверный фреймворк?
Или клиентский интерфейс?
PS. К сожалению, на моём горьком опыте, любая попытка программистов облегчить жизнь дизайнерам-верстальщикам, не узнав их мнения, заканчивалась плачевно.
Давайте отделим мясные продукты от насекомых. Что вы делаете?
Серверный фреймворк?
Или клиентский интерфейс?
PS. К сожалению, на моём горьком опыте, любая попытка программистов облегчить жизнь дизайнерам-верстальщикам, не узнав их мнения, заканчивалась плачевно.
Мы делаем фреймворк пользовательского интерфейса (и немного еще ;-). Он вклчюает как серверные компоненты, так и клиентские контроллеры. Без эффективного взаимодействия этих двух вещей, мы бы не получили нужного результата, но теперь, когда есть работающие проекты и за их реализацию и код мне не стыдно, хочу сказать - Это Работает.
P.S. У нас другой опыт, позитивный.
P.S. У нас другой опыт, позитивный.
хочу сказать - Это Работает
И это прекрасно! В разделе "проекты на Adept" я не нашел проектов со сколько-нибудь сложной логикой, но желаю, чтобы они у вас были и там тоже работало.
Но только это не серверный фреймворк. И с областью MVC никак не пересекается.
Вы написали кучу классов с логикой, оперирующей простыми структурами данных типа (select .... where id = _число_). Подцепили к классам контроллеры и какое то множество шаблонов представления.
И такое ощущение, что вызов этих классов происходит через функции, зарегистрированные как кастомные smarty-плагины (типа html select). А ведь на самом деле так можно сделать со Smarty!
Имхо, вы сделали мощный шаблонизатор, но засунув в него логику, вы обеспечили разрыв мозга на сложном проекте.
И такое ощущение, что вызов этих классов происходит через функции, зарегистрированные как кастомные smarty-плагины (типа html select). А ведь на самом деле так можно сделать со Smarty!
Имхо, вы сделали мощный шаблонизатор, но засунув в него логику, вы обеспечили разрыв мозга на сложном проекте.
На самом деле мы пробывали такое делат со Smarty, не получилось, могу объяснить почему, но лучше сделаю позже или при личном общении. Сверхлогики в шаблонизаторе нет, шаблонизатор удобнее Smarty хотя бы тем, что имеет среду со всеми фишечками и не практически отличается синтаксисом от *ML языков.
Синтаксис от *ML языков не так важен. Если верстальщик вменяемый, то он быстро врубается, как вызвать метод в классе и передать в него аргументы.
А как вам следующий случай: в проекте А вам нужен компонент "дерево, причем ветки должны догружаться ассинхронно, и реализовать добавление удаление". А на проекте Б вам понадобилось похожее дерево только с большей функциональностью, чем манипуляции даными, например сложные вычисления или генерирование документов, да все что угодно...
Куда вы разместите эту логику? Да так, чтобы эта логика осталась только в проекте Б, а общий код с компонентом из проекта А не дублировался
А как вам следующий случай: в проекте А вам нужен компонент "дерево, причем ветки должны догружаться ассинхронно, и реализовать добавление удаление". А на проекте Б вам понадобилось похожее дерево только с большей функциональностью, чем манипуляции даными, например сложные вычисления или генерирование документов, да все что угодно...
Куда вы разместите эту логику? Да так, чтобы эта логика осталась только в проекте Б, а общий код с компонентом из проекта А не дублировался
Наследуете компонент Б от компонента А и реализовываете недостающую функциональность
Правильно, что наследуете, но...
Значит ли это, что вы засовываете "сверхлогику в шаблонизатор"??
Ваш коллега voyacheg говорит обратное.
Мне интересна принципиальная схема устройства вашего компонета
Значит ли это, что вы засовываете "сверхлогику в шаблонизатор"??
Ваш коллега voyacheg говорит обратное.
Мне интересна принципиальная схема устройства вашего компонета
в рамках mvc валидация прикручивается в модели, а если её еще надо самому прикрутить где то еще - то это просто недостатки фреймворка
Дополнять. Сервер обязателен для защиты данных, а клиент - необходим для большей юзабельности.
именно так.
То есть вы считаете что Модель данных должна думать пришел ли ей правильный email или нет?
Я тоже так считаю :)
Именно поэтому обычно валидацию делят на страничную, и модельную (бизнес). Ну не улыбает меня проверять на валидность данные попавшие в одну модель, но из разных источников.
Именно поэтому обычно валидацию делят на страничную, и модельную (бизнес). Ну не улыбает меня проверять на валидность данные попавшие в одну модель, но из разных источников.
Так мы и говорим что если правила валидации не относятся к бизнес-слою, например пользователь дата редактирования не должна быть меньше даты создания, то проблему может решить компонет валидатор.Причем написав вот такую констркукцию <a:emailValidator /> то одновременно добавится проверка на клиенте(для удобства пользователя) и на сервере (на всякий пожарный)
Как согласен... Php должен: контроллером словить зависимость, подготовить запрос к БД. Послать... :) Получить от него данные. Отдать интерфейсу, скорее всего JSF. Всё. А писать PHP framework-и неблагодарное дело. Да и не надо они уже сильно. JS Framework-и. Это другое дело.
А для например cms хватит и двух классов. Controller и Core - всё. Остальное всё решается тем же jquery например.
Так что зря MVC похоронили... умные люди не зря его облилеяли, его вполне хватает.
Я считаю надо расширять JS IDE и Framework.
А для например cms хватит и двух классов. Controller и Core - всё. Остальное всё решается тем же jquery например.
Так что зря MVC похоронили... умные люди не зря его облилеяли, его вполне хватает.
Я считаю надо расширять JS IDE и Framework.
Думаю, что тот MVC, который закрепился в головах вместе в symphony, Rails и бригадой, лишь переходный этап в эволюции, аналогично переходу дескопов к использованию стандартных библиотек компонент, вместо самостоятельных поделок, которые рисовали кнопочки, ловили мышь, и имели с десяток "самоплаьных" элементов.
А вам не кажется, что веб уже практически догнал десктоп? Что сейчас все, что можно из декстопного переносят в веб
Смотря в чем.
В распространенности, удобстве и т.п? Хз. я не об этом.
Догнал, не догнал, он основан по прежнему на клиент-серверной архитектуре и протоколе HTTP.
В распространенности, удобстве и т.п? Хз. я не об этом.
Догнал, не догнал, он основан по прежнему на клиент-серверной архитектуре и протоколе HTTP.
в тех приложениях которые мы используем каждый день. К примеру у меня уже давно нет почтового клиента на машине, а если я сажусь за чей-то компьютер и мне нужо зайти в IM, то я использую Meebo, а для хрениния фоток - пикасса, или фликр.
Так в том-то и идея, чтобы абстрагироватсья от протолока нижнего уровня и разрабатывать на хорошей компонентной архитектуре, которая сгладит нюансы и шероховатости http, html да хоть кроссбраузерности.
Сгладить полностью нюансы HTTP и кроссбраузерности сможет только кардинальная переработка HTTP и захват 90% рынка браузеров одним.
Попытки построить над всем этим какую-то абстракцию предпринимались не раз и не только питерскими дизайн-студиями, но и, например, корпорацией MicroSoft.
Некоторые продукты довольно забавны — позволяют слобоквалифицированному программисту собрать готовый сайт из стандартных компонент.
Но при сложном программировании отрешение от самих основ архитектуры ни к чему хорошему не ведет.
Попытки построить над всем этим какую-то абстракцию предпринимались не раз и не только питерскими дизайн-студиями, но и, например, корпорацией MicroSoft.
Некоторые продукты довольно забавны — позволяют слобоквалифицированному программисту собрать готовый сайт из стандартных компонент.
Но при сложном программировании отрешение от самих основ архитектуры ни к чему хорошему не ведет.
В реалии, никто не предлагает на 100% потерять контроль над HTTP. Базисные сущности такие, как запрос-ответ-сессия-куки доступны в любой момент.
Идея - дополнить низкий уровень высоким.
Прекрасно понимая суть проблем сложным ресурсов, скажу, что синтез двух подходов - лучший путь для разработчика.
Идея - дополнить низкий уровень высоким.
Прекрасно понимая суть проблем сложным ресурсов, скажу, что синтез двух подходов - лучший путь для разработчика.
На мой взгляд (имхошный) это является смешиванием несмешиваемого.
Нужно четко различать, где клиент, где сервер.
Клиентский интерфейс и серверная логика, это совершенно различные вещи, требующие внимания специалистов совершенно различного профиля.
Нужно четко различать, где клиент, где сервер.
Клиентский интерфейс и серверная логика, это совершенно различные вещи, требующие внимания специалистов совершенно различного профиля.
Вы учитывайте, что многие из читающих этот пост, специалисты-универсалы?
Я тоже универсал. И тоже часто приходится на два фронта работать. Но я всегда разделяю, где gro-пыхер, а где gro-жаваскрипщик.
Вот смотрите вам нужно сделать, ну предположим, дерево, причем ветки должны догружаться ассинхронно, и реализовать добавление удаление и т.д. Вы конечно начинаете работать на два фронта и наверное все таки его сделаете. Потом вам будет нужно такое же дерево в другом проекте и вы вынуждены будете копипастить. Так не лучше ли сделать один раз компонент, который инкапсулирует всю логику работы с деревом и плодотворно и долго использовать его вов всех своих проектах? На счет того что у нас не серверный фреймворк.
Здесь нам нужно:
1. Написать библиотеку, упрощающую работу с древовидными данными. Использовать её везде, где она упростит работу с деревьями, а не только для этого конкретного случая.
2. Написать обработчики запросов к серверу на определенные данные (например, список дочерних узлов в определенном дереве). Можно использовать библиотеку из (1). Не забыть про проверку привилегий и т.п.
3. Реализовать клиентскую часть (html+js) нашего конкретного дерева. Один из его аспектов будет — подгрузка ветвей (можно использовать обработчики из (2)).
Прекрасно. Но ничего оригинального.
Какая связь всё той же концепции повторного использования кода с вашим фреймворком, паттерном MVC и обсуждаемым в данной ветке протоколом HTTP?
1. Написать библиотеку, упрощающую работу с древовидными данными. Использовать её везде, где она упростит работу с деревьями, а не только для этого конкретного случая.
2. Написать обработчики запросов к серверу на определенные данные (например, список дочерних узлов в определенном дереве). Можно использовать библиотеку из (1). Не забыть про проверку привилегий и т.п.
3. Реализовать клиентскую часть (html+js) нашего конкретного дерева. Один из его аспектов будет — подгрузка ветвей (можно использовать обработчики из (2)).
Прекрасно. Но ничего оригинального.
Какая связь всё той же концепции повторного использования кода с вашим фреймворком, паттерном MVC и обсуждаемым в данной ветке протоколом HTTP?
В вашем случае я бы перенес насколько возможно больше логики на сервер. Тогда ваши javascript`ы для асинхронной подгрузки кусков дерева стали бы по сложности не больше чем рюшечками вдовесок к простому html. И компонент станет "почти что полностью серверным", тогда и переносить легче, если логика в одном месте.
Вывод: размазывать логику и по клиенту и по серверу не айс.
Вывод: размазывать логику и по клиенту и по серверу не айс.
Полностью согласен с этим и несколькими Вашими мнениями выше. За неимением времени - увы, не могу включиться в дисскусию, но считаю необходимым поддержать здравую мысль.
А чего, молодцы.
MVC никакого отношения к реюзабельности кода не имеет.
насколько реюзабельны будут компоненты? как у вас с этим сейчас дела? :)
насколько реюзабельны будут компоненты? как у вас с этим сейчас дела? :)
Ну раз написав компонент, ты можешь использовать его функционал на любом проекте. Так что получается 100% :-) Подробнее можно почитать здесь
Хм. Посмотрел сайты написанные с использованием данного фреймворка. Довольно таки не плохая коллекция. Да и работают они шустренько. Видно что не тяп-ляп клепали.
Чтото по описанию получился Asp.Net. Собственно ASP.net слизан с Java Jsp. Ну както так.
Судя по картинке календарь очень напоминает http://www.dynarch.com/projects/calendar…
Полностью поддержу вас. У самого в голове возникали подобные мысли - надоело каждый раз иметь дело с тем, что действительно можно вынести в отдельные компоненты и от проекта к проету, менять CSS настраивая внешний вид
Круто! Очень рад что мы не одни такие :-) можете зарегистрироваться у нас на сайте и принимать участие в наших потугах
Странно у нас "лисенок" основной браузер. Можете обьяснить по-подробней что не работает и вашу систему и мы поправим
http://www.ImageShack.us
Зашёл на http://adept-project.com/framework, привычно нажать ctrl-+. Весь текст уполз в узкую полоску слева.
FF 2.0.0.12 WinXP
FF 2.0.0.12 WinXP
Прочитал статью "Кастомизация и скинабилити" на сайте фреймворка. Думаю что использование своего рендерера очень удобная вещь. Вобщем будем ждать исходников, чтоб попробовать как говориться на вкус.....
имхо, каждый должен в своей жизни написать свой фреймворк (пусть даже не долизать его до идеала).
за интеграцию с ZendFramework отдельное спасибо, надеюсь, получится действительно стоящий продукт!
По крайней мере на словах все выглядит очень интересно.
Но, естественно, надо смотреть, пробовать, препарировать.
Выкладывайте поскорее код.
Подписался на rss, буду следить за новостями.
Но, естественно, надо смотреть, пробовать, препарировать.
Выкладывайте поскорее код.
Подписался на rss, буду следить за новостями.
Хорошо пишите.
Только вот, как мне кажется, немного сомнительно пиарить проект, когда он еще не готов. Аудитория забудет.
Я, конечно, подписался на RSS новостей, и буду ждать, когда вы сможете дать посмотреть и пощупать. Надеюсь, не будете «зендить» или «айонкьюбить» (:
Спасибо за луч света в темном царстве!
Только вот, как мне кажется, немного сомнительно пиарить проект, когда он еще не готов. Аудитория забудет.
Я, конечно, подписался на RSS новостей, и буду ждать, когда вы сможете дать посмотреть и пощупать. Надеюсь, не будете «зендить» или «айонкьюбить» (:
Спасибо за луч света в темном царстве!
Select Press - респект. Не мозолит глаза. :-) Пункт testimonials не оранжевеет при переходе на него, а должен бы.
Парни, я жмакаю на УРЛо
h t t p://adept-project.com/framework/
Получаю:
===================================================================
Adept_Exception_IllegalArgument
Message 'Cannot locate config file: cache.xml '
File '/home/projects/adept-project.com/lib/Adept/ConfigLoader.php'
Line 63
Source
locale($file);
if ($locatedFile === false) {
throw new Adept_Exception_IllegalArgument("Cannot locate config file: {$file} ");
}
// Lookup in cache
if (isset($this->configs[$locatedFile])) {
return $this->configs[$locatedFile];
}
?>
Trace
at Adept_ConfigLoader->load(), line: 20
at Adept_Filter_Cache->__construct(), line: 109
at Adept_Application->configureFilter(), line: 136
at Adept_Application->initFilters(), line: 67
at Adept_Application->init(), line: 207
at Adept_Application->run(), line: 11
===================================================================
Не много ли информации для случайного прохожего? ;)
В целом хотелось бы видеть на сайте поболе технической информации о движке(честно говоря уже надоело качать-устанавливать-стирать "фреймворки"), и поменьше счастливых фейсов уже внедривших сей продукт (становится похожим на Битрикс, мое сугубо личное IMHO).
Удач!
h t t p://adept-project.com/framework/
Получаю:
===================================================================
Adept_Exception_IllegalArgument
Message 'Cannot locate config file: cache.xml '
File '/home/projects/adept-project.com/lib/Adept/ConfigLoader.php'
Line 63
Source
locale($file);
if ($locatedFile === false) {
throw new Adept_Exception_IllegalArgument("Cannot locate config file: {$file} ");
}
// Lookup in cache
if (isset($this->configs[$locatedFile])) {
return $this->configs[$locatedFile];
}
?>
Trace
at Adept_ConfigLoader->load(), line: 20
at Adept_Filter_Cache->__construct(), line: 109
at Adept_Application->configureFilter(), line: 136
at Adept_Application->initFilters(), line: 67
at Adept_Application->init(), line: 207
at Adept_Application->run(), line: 11
===================================================================
Не много ли информации для случайного прохожего? ;)
В целом хотелось бы видеть на сайте поболе технической информации о движке(честно говоря уже надоело качать-устанавливать-стирать "фреймворки"), и поменьше счастливых фейсов уже внедривших сей продукт (становится похожим на Битрикс, мое сугубо личное IMHO).
Удач!
Было бы очень интересно покрутить Ваш фреймворк в руках. Некоторое время назад я тоже планировал писать событийно-ориентированный фреймворк. Но дальше проекта дело не пошло в силу ряда причин.
Подписался на RSS. Буду ждать публичной версии
Подписался на RSS. Буду ждать публичной версии
В причинах в пользу Adopt вы пишете, что поддерживаете AOP. Очень интересно было бы посмотреть на реализацию. Ждем код))
форум у вас не работает, выдает 404 (ищет http://adept-project.willy/ ) при попытках завести новую тему или зарегистрироваться.
маленькое дополнение:
добавьте пожалуйста в список IDE, заполняемый при регистрации IntelliJ Idea.
маленькое дополнение:
добавьте пожалуйста в список IDE, заполняемый при регистрации IntelliJ Idea.
Немножко офтоп.
hedin
hedinА как у вас дело с ORM обстоит ?
Пишется ;-)
На самом деле первая реализация ORMа у нас готова и даже работает на нескольких проектах.
Но в силу того, что писали мы ее для нужд конкретного проекта, то код не в том состоянии, чтобы его показывать публично.
Но в силу того, что писали мы ее для нужд конкретного проекта, то код не в том состоянии, чтобы его показывать публично.
На мой взляд ORM составляющую лучше не трогать. Propel и Doctrine уже не догнать.
Лучше бросить все силы именно на AOP часть где проект пионер.
Лучше бросить все силы именно на AOP часть где проект пионер.
да они же параноидальные, сколько % функционала ты использовал больше 20% ????
15% в самом лучшем случае. Но к чему этот вопрос?
Вопрос к тому, что нет смысла использовать такие монстроедальные классы. От большего кол-ва ручек на двери, дверь открывать удобнее не станет.
Имхо всякие propel doctrine adodb - это некий концептуальный ивзрат из серии: "Фигасе я придумал".
Имхо всякие propel doctrine adodb - это некий концептуальный ивзрат из серии: "Фигасе я придумал".
Ты хорошо смотрел архитектуру того-же Doctrine? К двери ставиться ровно тот набор ручек который тебе нужен. Зато знаешь что, когда потребуется домофон, дверной глазок, и противопожарная защита, что эти их не проблема поставить и они прекрасно подойдут к твоей двери.
Doctrine - это наиболее проработанный и полный orm фреймворк их всех что я видел под пхп. В тоже время обладающий модульную структурой позволяющий не тащить ВСЮ его функциональность в приложение.
Еще раз подчеркиваю свою мысль. Не стоит изобретать очередной велосипед сомнительного качестве. А сфокусироваться на том что отличает этот фреймворк от других: событийная модель.
Doctrine - это наиболее проработанный и полный orm фреймворк их всех что я видел под пхп. В тоже время обладающий модульную структурой позволяющий не тащить ВСЮ его функциональность в приложение.
Еще раз подчеркиваю свою мысль. Не стоит изобретать очередной велосипед сомнительного качестве. А сфокусироваться на том что отличает этот фреймворк от других: событийная модель.
Тезис о том, что ставиться ровно столько, сколько заказывал ложный.
Во-первых, существуют разные модели построения библиотек по одной из версий их 9 и в зависимости от модели, разная степень избыточных методов при инициализации.
Во-вторых, benchmark всему голова :D
Пример сценария:
Ты подключаешь "большой" файл, который тащит за собой небольшое кол-во файлов на "все" случаи жизни.
Ты подключаешь "маленький" файл, который представляет из себя "lego", в результате чего, при наращивании функционала, открывается все большее кол-во файлов и плодятся наследуемости\инкапсуляции и прочие шалости ооп.
Класс, обрабатывается целиком перед выполнением, как на ошибки, так на инициализацию расходуется системное время\память.
Во-первых, существуют разные модели построения библиотек по одной из версий их 9 и в зависимости от модели, разная степень избыточных методов при инициализации.
Во-вторых, benchmark всему голова :D
Пример сценария:
Ты подключаешь "большой" файл, который тащит за собой небольшое кол-во файлов на "все" случаи жизни.
Ты подключаешь "маленький" файл, который представляет из себя "lego", в результате чего, при наращивании функционала, открывается все большее кол-во файлов и плодятся наследуемости\инкапсуляции и прочие шалости ооп.
Класс, обрабатывается целиком перед выполнением, как на ошибки, так на инициализацию расходуется системное время\память.
Подобный Фрейм ворк моя мечта!
Было бы что посмотреть получили бы конструктивную критику и сели бы дописывать свой фреймворк, а так говорить пока не о чем
увидев http://adept-project.com/quickstart/ как-то не захотелось переходить на третий шаг =)
а вообще, интересная штука. только я вроде (!) уже такое видел.
и давно хотел сам писать только влом было :)
а вообще, интересная штука. только я вроде (!) уже такое видел.
и давно хотел сам писать только влом было :)
Ну с этим можно поспорить например парни из 37sugnals говорят обратное. Что касается моделей данных, то у нас есть ORM и мы надеемся его анонсировать в ближайшем будущем.Не все сразу ;-)
Веб-приложениями пользуются живые люди (причем различной степени подготовленности) и им глубоко фиолетово до модели данных (а большая их часть вообще не знает что это).
Поверьте, их больше волнует, почему они вынуждены работать со страницами на которых натыкано 10 разных кнопок, и еще 20 полей для ввода. А так бывает, когда программисты сначала создают модель данных, а потом пытаются из того, что получилось выстроить интерфейс взаимодействия с пользователем.
По моему опыту, успешность сайта определяется не красотой внутренней архитектуры или выбором "правильной платформы", а удобством для пользователя. Если пользователю интерфейс покажется сложным или не интуитивно понятным, то скорее всего он уйдет и никогда на ресурс не вернется.
Программист должен постоянно держать в голове бизнес-цель разрабатываемого приложения, и как можно меньше отвлекаться на такие вещи, как защита от XSS или на то, почему у него в MSIE не работает javascript-календарь.
Собственно, ребята из 37signals примерно про это и говорят.
Поверьте, их больше волнует, почему они вынуждены работать со страницами на которых натыкано 10 разных кнопок, и еще 20 полей для ввода. А так бывает, когда программисты сначала создают модель данных, а потом пытаются из того, что получилось выстроить интерфейс взаимодействия с пользователем.
По моему опыту, успешность сайта определяется не красотой внутренней архитектуры или выбором "правильной платформы", а удобством для пользователя. Если пользователю интерфейс покажется сложным или не интуитивно понятным, то скорее всего он уйдет и никогда на ресурс не вернется.
Программист должен постоянно держать в голове бизнес-цель разрабатываемого приложения, и как можно меньше отвлекаться на такие вещи, как защита от XSS или на то, почему у него в MSIE не работает javascript-календарь.
Собственно, ребята из 37signals примерно про это и говорят.
Вот о том я и говорю. Я достаточно насмотрелся проектов с красивой схемой хранения и кучей непонятных форм, кнопок и т.д. Пользоваться такими проектами было не возможно
Фреймворк этот завут ASP/ASP.Net и существует он сами знаете сколько лет.
ждем исходников
захожу на сайт - на всех страницах IE пишет ошибку яваскрипта
Делать свои фреймворки нужно и правильно. Без этого сложно стать действительно профессиональным программистом. При разработке фреймворков получается столько граблей и интересных моментов, что после длительной работы над таким проектом - у вас уже появляется довольно широкий кругозор и профессиональный взгляд на код. Вы начинаете понимать - когда стоит писать фреймворки/движки, а когда надо echo "...";.
Путь к созданию фреймворков - путь к универсальности. Но реальные проекты - не требуют такой универсальности. ASP.NET предоставляет сотни свойств для каждого компонента, из которых я использую максимум 5%, а остальная универсальность лишь напрягает процессор и память.
Когда четко известны требования к проекту - его легко выполнить даже обычным PHP/HTML смешением.
Путь к созданию фреймворков - путь к универсальности. Но реальные проекты - не требуют такой универсальности. ASP.NET предоставляет сотни свойств для каждого компонента, из которых я использую максимум 5%, а остальная универсальность лишь напрягает процессор и память.
Когда четко известны требования к проекту - его легко выполнить даже обычным PHP/HTML смешением.
Правда я не разу еще не видел проект с четкими требованиями и с условием что ты напишешь раз и забудешь. Всегда приходится что то подправлять изменять. И вот тут то "лапша" показывает себя с очень плохой стороны
Требования к проекту хороши на бумаге. Потому что когда ты ее читаешь ты точно знаешь что от тебя требуется и как можно достичь этого с минимальными усилиями.
Только вот главное не забывать что когда ты это все напишешь у людей появятся новые желания и новые требования.
Имхо это тоже большая такая грабля которая больно бьет, когда на неё наступаешь
Только вот главное не забывать что когда ты это все напишешь у людей появятся новые желания и новые требования.
Имхо это тоже большая такая грабля которая больно бьет, когда на неё наступаешь
"Когда четко известны требования к проекту - его легко выполнить даже обычным PHP/HTML смешением."
Неужели тебе не приходилось сталкиваться с тем, что сегодня у заказчика одно видение, а завтра, он увидел где-то там AJAX-фигнюшечку или что-то еще и скажет: "хочу так же". А еще скажет то-то и то-то доделать. А вот когда у тебя есть в руках такой мощный инструмент, как фреймворк - решить такую проблему не составит труда.
А ведь в 90% случаев от исходных требований к проекту остается маленькая толика...
Неужели тебе не приходилось сталкиваться с тем, что сегодня у заказчика одно видение, а завтра, он увидел где-то там AJAX-фигнюшечку или что-то еще и скажет: "хочу так же". А еще скажет то-то и то-то доделать. А вот когда у тебя есть в руках такой мощный инструмент, как фреймворк - решить такую проблему не составит труда.
А ведь в 90% случаев от исходных требований к проекту остается маленькая толика...
Стив Макконнел писал "Требования изменчивы". С этим сложно не согласиться.
Но чтобы построить будку собаке не нужен подъемный кран и группа строителей.
Вы должны четко понимать для каких целей ваш фреймворк.
Для упрощения всего и вся? Такое не подойдет. Любая универсальность - усложняет.
Стив Макконнел писал "Боритесь со сложностью".
Делайте выводы.
Но чтобы построить будку собаке не нужен подъемный кран и группа строителей.
Вы должны четко понимать для каких целей ваш фреймворк.
Для упрощения всего и вся? Такое не подойдет. Любая универсальность - усложняет.
Стив Макконнел писал "Боритесь со сложностью".
Делайте выводы.
посмотрел.
молодцы, поздравляю. интересная система.
хотя я лично для себя выбрал CakePHP, решив не изобретать велосипедов.
молодцы, поздравляю. интересная система.
хотя я лично для себя выбрал CakePHP, решив не изобретать велосипедов.
вроде бы есть похожее - Delphi for PHP
кнопки рисуются, привязываются к ним события и т.п.
кнопки рисуются, привязываются к ним события и т.п.
Не писать фреймворков :) А может ваще ничё не писать. Всё индусы напишут. А ты только копипасть и грепи копейки. Втопку!
Жесть. А какая лицензия?
Этот фреймворк платный или бесплатный?
По третьему пункту мама не права. Писать надо. Хотя бы для того чтобы учиться что-то делать.
Что до сабжа, то лично меня кривая дорожка фреймописательства привела к отсутствию необходимости в "универсальном" фреймворке. Считаю внесение бизнес-логики в php для сколь-нибудь серьезных проектов ошибкой. Логику из php переносится на сервер БД. Задачи пхп - обеспечить безопасный вызов хранимых процедур из интерфейса пользователя - это раз, и обеспечить вменяемую выдачу данных клиенту - это два.
Компонентная модель отправляется на сторону клиента (у меня все необходимые библиотеки требуют загрузки 90кб жаваскрипта), плюс логика, зашитая в модулях, юзающих эти компоненты - загружается по требованию.
Ядро сервера - это 4 core файла, управляющие работой системы и множество datasource/command файлов, реализующих связку клиента с базой данных.
Что до сабжа, то лично меня кривая дорожка фреймописательства привела к отсутствию необходимости в "универсальном" фреймворке. Считаю внесение бизнес-логики в php для сколь-нибудь серьезных проектов ошибкой. Логику из php переносится на сервер БД. Задачи пхп - обеспечить безопасный вызов хранимых процедур из интерфейса пользователя - это раз, и обеспечить вменяемую выдачу данных клиенту - это два.
Компонентная модель отправляется на сторону клиента (у меня все необходимые библиотеки требуют загрузки 90кб жаваскрипта), плюс логика, зашитая в модулях, юзающих эти компоненты - загружается по требованию.
Ядро сервера - это 4 core файла, управляющие работой системы и множество datasource/command файлов, реализующих связку клиента с базой данных.
По мне так это просто очередной кривой велосипед. До удобства, скорости, надёжности и универсальности ASP.Net ему не дотянуть никогда.
Создание нового фреймворка - конечно полезный опыт, но иногда просто лучше просто научиться решать задачи эффективным путём.
Задумайтесь над тем фактом, что ваша идея слишком сильно держится на слове "PHP". Убрать его, и решение вашей задачи станет простым, да ещё и будет выбор из нескольких вариантов.
Создание нового фреймворка - конечно полезный опыт, но иногда просто лучше просто научиться решать задачи эффективным путём.
Задумайтесь над тем фактом, что ваша идея слишком сильно держится на слове "PHP". Убрать его, и решение вашей задачи станет простым, да ещё и будет выбор из нескольких вариантов.
>> Мы решили сделать разработку интерфейсной части такой же простой, как и в десктопных приложениях. Мы отказались от классической MVC, заменив ее компонентной архитектурой. То есть, решили создать набор стандартных UI компонентов (кнопки, чекбоксы, радиокнопки, текстовые поля, таблицы), как и в десктопных приложениях, и просто строить интерфейс из этих компонентов.
а чем вам классы форм (в ZF Zend_Form) и хелперы не устроили?
а чем вам классы форм (в ZF Zend_Form) и хелперы не устроили?
Автор, я тебя люблю (not gay). Отличную вещь делаете. Умоляю, не бросайте это.
новый гламурный фреймворк!
посмотрел примеры http://adept-project.com/projects/ большое количество проектов не проходят валидацию html-валидатора, впрочем как и сам http://adept-project.com/. Это конечно занудство и ни в коем случае не умаляет идеи, но валидность компонент вещь необходимая :). Еще я понял, что весь js - свой - как насчет кроссброузерности?
как там у Лебедева было? Лучший валидатор — это браузер. :)
Тем более в разделе "проекты" большая часть сайтов делалась другими командами. Адепт не настолько прекрасен, чтобы еще делать самому валидный HTML. :)
Что касается js — насколько мне известно, тестирование производится минимум в трех браузерах FF, MSIE, Opera. И довольно много времени при разработке компонентов тратится именно на кроссбраузерность. hedin не даст соврать )
Тем более в разделе "проекты" большая часть сайтов делалась другими командами. Адепт не настолько прекрасен, чтобы еще делать самому валидный HTML. :)
Что касается js — насколько мне известно, тестирование производится минимум в трех браузерах FF, MSIE, Opera. И довольно много времени при разработке компонентов тратится именно на кроссбраузерность. hedin не даст соврать )
Несмотря даже на то что мы используем prototype больше половины времени уходит на борьбу с браузерами. С версткой такая же беда иногда валидный код браузер рендерит не пойми как и наоборот
SQL инъекция на сайтике av-moskovsky.ru присутствует ;)
Звучит интересно. Плюс отличный юмор разработчиков :) Желаю удачи, слежу за новостями
Молодцы. А что вы скажете насчет ExtJS? Или я что-то не понимаю и к теме это не относится?
Много букв, и концептуальных моно\диа-логов.
В принципе "+", что изобретаете велосипед, а иначе он никогда не полетит :)
Концепт он как воздух - его можно гонять веками, без сырцов - это не более чем пиар.
В принципе "+", что изобретаете велосипед, а иначе он никогда не полетит :)
Концепт он как воздух - его можно гонять веками, без сырцов - это не более чем пиар.
Такой вопрос: А почему бы не использовать ASP.NET?
Исходные коды Adept, а также Adept IDE уже доступны на adept-project.com. Да и еще бонус: видео-урок, как установить и создать HelloWorld приложение.
Красавцы, пожалуйста, почините регистрацию у себя на сайте. Аккаунт не активируется ни в какую...
И еще, из коробки по видео-туториалу поставил, на работает:
И еще, из коробки по видео-туториалу поставил, на работает:
Fatal error: Class 'Adept_Template_MetaInfo' not found in D:\Workspace\TestAdeptProject\lib\Adept\Controller\Lifecycle.php on line 102
У меня на харде такая платформа валяется уже года два-три. Все очень круто, только я совершил большую ошибку поставив на XML (Хранил в нем лейаут и состояние страницы), а он оказался очень медленным. Вот поэтому и пылится.
что-то пока нормальных и качественных проектов на Adept не наблюдается
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
От лапши к компонентам или Слушайтесь родителей!