Как стать автором
Обновить

Комментарии 247

Чо-та по описанию напоминает Hop - язычок, который зараз задает поведение на сервере и клиенте.
Нет по идеологии Адепт похож на спецификацию JSF от sun
При том JSF на практике оказалась штукой довольно своеобразной и не всегда приятной: разные библиотеки компонентов могут конфликтовать друг с другом, компоненты генерируют кучу джаваскрипта, на одной странице не может быть более 1-й функциональной формы.
на одной странице не может быть более 1-й функциональной формы
ASP.NET? Если да, то кто у кого гм-гм идею?
Ну старались взять только хорошее у JSF. У нас на страници может быть сколько угодно форм.
О, это приятно!
проект интересный. А как познакомиться с ним можно? (я про сорсы)
Мы сейчас активно доводим код до такого состояния,чтобы его можно было показать людям(php-доки, лицензия и т.д.). Поэтому как доделаем так сразу же и выложим. Ориентировочно к концу февраля.
Для того, чтобы понять "а оно нам нада?" нужно понять сколько вообще среди "программистов" на PHP есть людей, понимающих хоть что-то в программировании. Способных что-то спроектировать и реализовать, а не просто дёргающих куски кода отовсюду, а потом удивляющихся что у них простейшая страничка 20 секунд грузится.

На Хабрахабре таких людей меньше "средней нормы по индустрии", но достаточно ли их чтобы поддержать ваш фреймворк ? Ему же придётся соревноваться с рельсами и GWT, а не с другими PHP-фреймворками (если судить чисто по описанию). Много ли людей захотят использовать вменяемый фреймворк на невменяемом языке - вот в чём вопрос...
Я довольно долго пишу на PHP и считаю его нормальным вменяемым языком(я имею ввиду 5). Вот вменяемых программистов там реально на порядок меньше чем среди других платформ. Но мы надеемся на лучшее :-)
PHP вменяемый язык, но, к сожелению слишком легкий для познания, что и превлекает кучу быдло кодеров, которые считают что ооп следует применять только для каких-то одних мифических целей, паттерны - зло и от лукавого, а написание кода в столбик - самый лучший способ и к тому же быстрый
В то же время по крайней мере мало кто будет спорить что преимущества ООП проявляются только в крупных проектах, постоянно подвергающихся рефакторингу и усложнению функциональности. Применять ООП только ради одного ООП это тоже быдлокодинг.
Не согласен. Здесь скорее повлияет сложность проекта чем его размер.
Прежде чем высказывать компетентное мнение по ООП, попробуйте поработать с ним какое-то время.
Ну и интересно сколько же надо писать на ООП, чтобы иметь право на мнение?
Писать нужно ровно до того момента, когда избавляетесь от чепушиных стереотипов полученных от супер-мега-хацкеров. Типа, ООП нужно применять только на больших проектах. А процедурное программирование на маленьких.
Позвольте спросить, а где тогда применять функциональное, аспектное, прототипное и другие?
Отвечаю: любая из технологий применима в случае необходимости и наличия здравой головы и умелых рук. Мы используем комбинации ООП, есть и реализация аспектной библиотеки (не анонсированная, но весьма перспективная).

Избавьтесь, от предрассудков. HTTP не должен вам указывать, как писать, не заостряйте свое внимание на более приятных вещах, чем запрос-ответ.
К сожалению, я не понял ни одного ответа на мои сообщения в данной ветке. Мой ответ был гражданину DmitriKadykov на фразу "преимущества ООП проявляются в только крупных проектах". Причем тут ваши аспектные библиотеки, протокол HTTP и мои предрассудки мне не понятно.
Нужно просто понять, что существует несколько парадигм программирования, в том числе и полностью объектная и что класс - это не только неймспейс с кучей фунцкий.
:-/ А что ещё?)
Наследование и полиформизм :)
и правда)
Спасибо за нормальное OOП суждение, а то я уже замучился всем постоянно повторять вашу фразу.
писать нужно до просветления ;) ;) ;)
Если вы - профи, то они вам мешают также, как дети на футбольном поле Бекхему.
скажем так, они мне не мешают никак, хотя иногда и попадаются подноги. Иногда просто задевают такие высказывания типа "php гавно и на нем тока дебилы пишут".
Согласен. Также как раньше в среде C++ программистам относились к "дельфятникам"
Боюсь вас обидеть, но мое отношение к делфи - хуже некуда :)
Стиль изложения - на пять с плюсом, по крайней мере, на мой вкус =) Ловите плюс.
Проект обязательно гляну, но позже..
Спасибо
НЛО прилетело и опубликовало эту надпись здесь
Просто 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 всеми необходимыми мастерами и шаблонами. Долой рутину, товарищи! ;-)
НЛО прилетело и опубликовало эту надпись здесь
К сожалению реализация этого продукта просто ужасна. Delphi for PHP невозможно пользоваться
Не знаю, как там внутри, но по описанию похоже на Prado (http://www.pradosoft.com/)
С одной стороны, наконец, кто-то не побоялся сказать страшную вещь: "Классические реализации MVC, не лучшим образом подходят для предметной области PHP". Потому что разработаны они изначально для десктопных графических приложений.

С другой, отказавшись от MVC, начали заниматься тем же самым — попыткой подогнать веб-систему под тот же десктоп.
А что в этом плохого? Мы пытаемся чтобы программист реализовывая web-проект думал о бизнес логике, а не о том, как с верстать HTML, чтобы получилось дерево, и как потом с этой конструкцией работать. Интересно, как бы люди писали GUI приложения, если бы им всегда нужно было вручную отслеживать положение мыши и в ручную заниматься отрисовкой UI компонент?
Вобще-то MVC как раз для того и используется, чтобы программист не верстал HTML.
Верстать должен верстальщик. А сам движок не должен изображать из себя верстальщика — ничего хорошего из этого не выйдет.
Отслеживанием же положения мыши занимается ОС клиента и движок его браузера. Вашего ответа я не понял. Я обратил внимание на то, что вы пытаетесь делать то, что вам не понравилось в MVC.
Создание же страницы из стандартных элементов, со стандартным поведением, это, скорее всего, JS-UI-библиотека, возможно, с некоторой серверной PHP-прослойкой.
То же, что называется "фреймворк", "движок" и т.п. должно работать в другой области — в хранении, преобразовании и выдаче данных, разделении привилегий, отслеживании сеансов, формировании вывода.
У PHP не должно быть никаких кнопок, контроллов и т.п. У него есть запрос, он должен отдать ответ и всё.
Если в этом самом конечном ответе будет задействован тот же JS-UI-немногоPHP-фреймворк, пожалуйста.
Программист не верстает, он проектирует интерфейс. В компонентно-событйином подходе мы отдаем компонентам валидацию (которую вы, наверняка, каждый раз прикручиваете в своем php модуле), конвертацию данных, и облегчаем жизнь нашему дизайнеру, которому не нужно сто раз выверстывать набальные элементы управления, формы и т.п., а достаточно подправить интерфейс.

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

Давайте отделим мясные продукты от насекомых. Что вы делаете?
Серверный фреймворк?
Или клиентский интерфейс?

PS. К сожалению, на моём горьком опыте, любая попытка программистов облегчить жизнь дизайнерам-верстальщикам, не узнав их мнения, заканчивалась плачевно.
Мы делаем фреймворк пользовательского интерфейса (и немного еще ;-). Он вклчюает как серверные компоненты, так и клиентские контроллеры. Без эффективного взаимодействия этих двух вещей, мы бы не получили нужного результата, но теперь, когда есть работающие проекты и за их реализацию и код мне не стыдно, хочу сказать - Это Работает.

P.S. У нас другой опыт, позитивный.
хочу сказать - Это Работает

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

Но только это не серверный фреймворк. И с областью MVC никак не пересекается.
то есть 1click-hosting и социальная афиша — не относится к проектам со сложной логикой?
А как по вашему?
Вы написали кучу классов с логикой, оперирующей простыми структурами данных типа (select .... where id = _число_). Подцепили к классам контроллеры и какое то множество шаблонов представления.

И такое ощущение, что вызов этих классов происходит через функции, зарегистрированные как кастомные smarty-плагины (типа html select). А ведь на самом деле так можно сделать со Smarty!

Имхо, вы сделали мощный шаблонизатор, но засунув в него логику, вы обеспечили разрыв мозга на сложном проекте.
На самом деле мы пробывали такое делат со Smarty, не получилось, могу объяснить почему, но лучше сделаю позже или при личном общении. Сверхлогики в шаблонизаторе нет, шаблонизатор удобнее Smarty хотя бы тем, что имеет среду со всеми фишечками и не практически отличается синтаксисом от *ML языков.
Синтаксис от *ML языков не так важен. Если верстальщик вменяемый, то он быстро врубается, как вызвать метод в классе и передать в него аргументы.

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

Куда вы разместите эту логику? Да так, чтобы эта логика осталась только в проекте Б, а общий код с компонентом из проекта А не дублировался
Наследуете компонент Б от компонента А и реализовываете недостающую функциональность
Правильно, что наследуете, но...
Значит ли это, что вы засовываете "сверхлогику в шаблонизатор"??
Ваш коллега voyacheg говорит обратное.

Мне интересна принципиальная схема устройства вашего компонета
в рамках mvc валидация прикручивается в модели, а если её еще надо самому прикрутить где то еще - то это просто недостатки фреймворка
НЛО прилетело и опубликовало эту надпись здесь
Дополнять. Сервер обязателен для защиты данных, а клиент - необходим для большей юзабельности.
именно так.
НЛО прилетело и опубликовало эту надпись здесь
То есть вы считаете что Модель данных должна думать пришел ли ей правильный email или нет?
Я тоже так считаю :)
Именно поэтому обычно валидацию делят на страничную, и модельную (бизнес). Ну не улыбает меня проверять на валидность данные попавшие в одну модель, но из разных источников.
НЛО прилетело и опубликовало эту надпись здесь
Так мы и говорим что если правила валидации не относятся к бизнес-слою, например пользователь дата редактирования не должна быть меньше даты создания, то проблему может решить компонет валидатор.Причем написав вот такую констркукцию <a:emailValidator /> то одновременно добавится проверка на клиенте(для удобства пользователя) и на сервере (на всякий пожарный)
Как согласен... Php должен: контроллером словить зависимость, подготовить запрос к БД. Послать... :) Получить от него данные. Отдать интерфейсу, скорее всего JSF. Всё. А писать PHP framework-и неблагодарное дело. Да и не надо они уже сильно. JS Framework-и. Это другое дело.
А для например cms хватит и двух классов. Controller и Core - всё. Остальное всё решается тем же jquery например.
Так что зря MVC похоронили... умные люди не зря его облилеяли, его вполне хватает.
Я считаю надо расширять JS IDE и Framework.
Думаю, что тот MVC, который закрепился в головах вместе в symphony, Rails и бригадой, лишь переходный этап в эволюции, аналогично переходу дескопов к использованию стандартных библиотек компонент, вместо самостоятельных поделок, которые рисовали кнопочки, ловили мышь, и имели с десяток "самоплаьных" элементов.
А вам не кажется, что веб уже практически догнал десктоп? Что сейчас все, что можно из декстопного переносят в веб
Смотря в чем.
В распространенности, удобстве и т.п? Хз. я не об этом.
Догнал, не догнал, он основан по прежнему на клиент-серверной архитектуре и протоколе HTTP.
в тех приложениях которые мы используем каждый день. К примеру у меня уже давно нет почтового клиента на машине, а если я сажусь за чей-то компьютер и мне нужо зайти в IM, то я использую Meebo, а для хрениния фоток - пикасса, или фликр.
И что?
Так в том-то и идея, чтобы абстрагироватсья от протолока нижнего уровня и разрабатывать на хорошей компонентной архитектуре, которая сгладит нюансы и шероховатости http, html да хоть кроссбраузерности.
Сгладить полностью нюансы HTTP и кроссбраузерности сможет только кардинальная переработка HTTP и захват 90% рынка браузеров одним.
Попытки построить над всем этим какую-то абстракцию предпринимались не раз и не только питерскими дизайн-студиями, но и, например, корпорацией MicroSoft.
Некоторые продукты довольно забавны — позволяют слобоквалифицированному программисту собрать готовый сайт из стандартных компонент.
Но при сложном программировании отрешение от самих основ архитектуры ни к чему хорошему не ведет.
В реалии, никто не предлагает на 100% потерять контроль над HTTP. Базисные сущности такие, как запрос-ответ-сессия-куки доступны в любой момент.
Идея - дополнить низкий уровень высоким.

Прекрасно понимая суть проблем сложным ресурсов, скажу, что синтез двух подходов - лучший путь для разработчика.
На мой взгляд (имхошный) это является смешиванием несмешиваемого.
Нужно четко различать, где клиент, где сервер.
Клиентский интерфейс и серверная логика, это совершенно различные вещи, требующие внимания специалистов совершенно различного профиля.
Вы учитывайте, что многие из читающих этот пост, специалисты-универсалы?
Я тоже универсал. И тоже часто приходится на два фронта работать. Но я всегда разделяю, где gro-пыхер, а где gro-жаваскрипщик.
Вот смотрите вам нужно сделать, ну предположим, дерево, причем ветки должны догружаться ассинхронно, и реализовать добавление удаление и т.д. Вы конечно начинаете работать на два фронта и наверное все таки его сделаете. Потом вам будет нужно такое же дерево в другом проекте и вы вынуждены будете копипастить. Так не лучше ли сделать один раз компонент, который инкапсулирует всю логику работы с деревом и плодотворно и долго использовать его вов всех своих проектах? На счет того что у нас не серверный фреймворк.
Здесь нам нужно:
1. Написать библиотеку, упрощающую работу с древовидными данными. Использовать её везде, где она упростит работу с деревьями, а не только для этого конкретного случая.

2. Написать обработчики запросов к серверу на определенные данные (например, список дочерних узлов в определенном дереве). Можно использовать библиотеку из (1). Не забыть про проверку привилегий и т.п.

3. Реализовать клиентскую часть (html+js) нашего конкретного дерева. Один из его аспектов будет — подгрузка ветвей (можно использовать обработчики из (2)).

Прекрасно. Но ничего оригинального.
Какая связь всё той же концепции повторного использования кода с вашим фреймворком, паттерном MVC и обсуждаемым в данной ветке протоколом HTTP?
В вашем случае я бы перенес насколько возможно больше логики на сервер. Тогда ваши javascript`ы для асинхронной подгрузки кусков дерева стали бы по сложности не больше чем рюшечками вдовесок к простому html. И компонент станет "почти что полностью серверным", тогда и переносить легче, если логика в одном месте.

Вывод: размазывать логику и по клиенту и по серверу не айс.
Ну а мы что делаем. Все что должно происходить на сервере делается на сервере, что должно делаться на клиенте делается на клиенте. По-моему программист вообще не должен знать где это происходит ему просто в должно придти событие которое надо обработать и все.
Это и есть как раз разделение слоя логики и представления данных. Да
Полностью согласен с этим и несколькими Вашими мнениями выше. За неимением времени - увы, не могу включиться в дисскусию, но считаю необходимым поддержать здравую мысль.
Спасибо за поддержку и её форму, отличную от "+1" :)
Спасибо! Присоединяйтесь
MVC никакого отношения к реюзабельности кода не имеет.

насколько реюзабельны будут компоненты? как у вас с этим сейчас дела? :)
Ну раз написав компонент, ты можешь использовать его функционал на любом проекте. Так что получается 100% :-) Подробнее можно почитать здесь
Хм. Посмотрел сайты написанные с использованием данного фреймворка. Довольно таки не плохая коллекция. Да и работают они шустренько. Видно что не тяп-ляп клепали.
Чтото по описанию получился Asp.Net. Собственно ASP.net слизан с Java Jsp. Ну както так.
Я уже писал выше что идеологическим прототипом была спецификация JSF. Просто мы постарались совместить гибкость и простоту PHP с основательностью java.
Js контроллер и взят оттуда. Просто для того чтобы тебе вставить поле с календарем такой календарем нужно всего лишь написать <a:datePicker />
Полностью поддержу вас. У самого в голове возникали подобные мысли - надоело каждый раз иметь дело с тем, что действительно можно вынести в отдельные компоненты и от проекта к проету, менять CSS настраивая внешний вид
Круто! Очень рад что мы не одни такие :-) можете зарегистрироваться у нас на сайте и принимать участие в наших потугах
НЛО прилетело и опубликовало эту надпись здесь
Странно у нас "лисенок" основной браузер. Можете обьяснить по-подробней что не работает и вашу систему и мы поправим
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Вам нужно поставить пакет MSTTCOREfonts и все заработает :-)
Нет, не думаю. У меня та же проблема - работает только, если на #body убрать overflow:auto;
НЛО прилетело и опубликовало эту надпись здесь
Ну поправь. Ради меня и ACL (:
Блин мы протестили на Firefox 2.0.0.11, Ubuntu 7.10 было все нормально. Что ж будем разбираться
увольте верстальщика. я за 5 минут нашел в чем проблема.
блок заголовка нужно ограничивать!

#main_image
{
...
overflow:hidden;
}
Спасибо! Уволили :-)
Зашёл на http://adept-project.com/framework, привычно нажать ctrl-+. Весь текст уполз в узкую полоску слева.
FF 2.0.0.12 WinXP
Проблема решена
Прочитал статью "Кастомизация и скинабилити" на сайте фреймворка. Думаю что использование своего рендерера очень удобная вещь. Вобщем будем ждать исходников, чтоб попробовать как говориться на вкус.....
НЛО прилетело и опубликовало эту надпись здесь
ну не только этот магазин шустро бегает, многие другие проекты также мгновенно грузяться ;)
мы просто не ожидали, что народ попрет толпой. Вот сейчас мы включили кеширование, так что время на загрузку сайта уменьшится
имхо, каждый должен в своей жизни написать свой фреймворк (пусть даже не долизать его до идеала).
имхо, время "фреймворк ради фреймворка" уже давно прошло
я не говорил ради фреймворка. Тем более для вашего проекта ваш фреймворк может оказаться куда лучше чем zend'овский или симфониевский.
Имхо, каждый web-программист проходит 3 стадии:
1. Написание своего фрейморк
2. Написание своей CMS
3. Посвещение всего себя одному из первых двух пунктов либо полный отказ от обоих.
Это вместо дома, дерева или сына?
за интеграцию с ZendFramework отдельное спасибо, надеюсь, получится действительно стоящий продукт!
Да, это также еще одна основшая фича.

Согласитесь, повторно реализовывать Locale, Mail etc просто тупо.
По крайней мере на словах все выглядит очень интересно.
Но, естественно, надо смотреть, пробовать, препарировать.
Выкладывайте поскорее код.
Подписался на rss, буду следить за новостями.
Хорошо пишите.
Только вот, как мне кажется, немного сомнительно пиарить проект, когда он еще не готов. Аудитория забудет.
Я, конечно, подписался на RSS новостей, и буду ждать, когда вы сможете дать посмотреть и пощупать. Надеюсь, не будете «зендить» или «айонкьюбить» (:
Спасибо за луч света в темном царстве!
В RSS мы также помещаем статьи из блога, в которых описываем решение проблем, с которыми часто сталкиваются многие веб-программисты.
Пожалуйста :-) Если честно не ожидали такой поддержки от сообщества
Select Press - респект. Не мозолит глаза. :-) Пункт testimonials не оранжевеет при переходе на него, а должен бы.
Не может такого быть! Все оранжевеет, проверь еще раз
Точно не оранжевеет.
Стоит nav-off, а должно nav-on , по идее
nav-off тут ни причем.. ссылка красится когда у нее class="current"
Проверил - тоже самое, все пункты нормально и только testimonials не оранжевеет.
Зайди на страницу отзывов и сделай скрин и выложи здесь. У меня все красится
Ни разу не вставлял картинки - сейчас попробую :)


P.S.:
вообще, тоже добавил в Rss - буду с интересом ждать исходников ;)
Я то думал это на сайте Adept'a!! А вы про Select Press :-) Сообщим о проблеме разработчикам сайта ;)
НЛО прилетело и опубликовало эту надпись здесь
Это мы кеш включали ;-)
НЛО прилетело и опубликовало эту надпись здесь
Ок, просто сайт лежит на полигонном сервере, все настройки там как для "домашних". Так, что чувствуйте себя как дома ;-)
НЛО прилетело и опубликовало эту надпись здесь
Парни, я жмакаю на УРЛо
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).

Удач!
Зато как красиво отрисовывается ;-) Следует знакомить со всеми возможностями продукта, пусть даже это и вывод Exception-а ;-).
Довольно таки информативный exception, в принципе всё что нужно для отладки :)
я бы еще дамп переменных добавил бы :)
У нас можно на тестовом сервер подключить специальный фильтр. Он показывает и переменные запроса, и cookies, и занимаемую память, и запросы к БД
Было бы очень интересно покрутить Ваш фреймворк в руках. Некоторое время назад я тоже планировал писать событийно-ориентированный фреймворк. Но дальше проекта дело не пошло в силу ряда причин.
Подписался на RSS. Буду ждать публичной версии
В причинах в пользу Adopt вы пишете, что поддерживаете AOP. Очень интересно было бы посмотреть на реализацию. Ждем код))
Кстати, у нас на подходе статья про использование АОР в Adept и в РНР вообще
Отлично. Было бы очень здорово! Обязательно почитаем.
форум у вас не работает, выдает 404 (ищет http://adept-project.willy/ ) при попытках завести новую тему или зарегистрироваться.

маленькое дополнение:
добавьте пожалуйста в список IDE, заполняемый при регистрации IntelliJ Idea.
Форум будет, когда запустим сам проект, то есть - выложим исходники
Немножко офтоп.
посмотреть профиль hedin, а вы от кого шифруетесь? :) Контакты на сайте только для зарегистрированных. Собственно, хотел написать, что у вас там трабла с масштабированием под FF2.
Пишется ;-)
На самом деле первая реализация ORMа у нас готова и даже работает на нескольких проектах.

Но в силу того, что писали мы ее для нужд конкретного проекта, то код не в том состоянии, чтобы его показывать публично.
На мой взляд ORM составляющую лучше не трогать. Propel и Doctrine уже не догнать.
Лучше бросить все силы именно на AOP часть где проект пионер.
да они же параноидальные, сколько % функционала ты использовал больше 20% ????
15% в самом лучшем случае. Но к чему этот вопрос?
Вопрос к тому, что нет смысла использовать такие монстроедальные классы. От большего кол-ва ручек на двери, дверь открывать удобнее не станет.
Имхо всякие propel doctrine adodb - это некий концептуальный ивзрат из серии: "Фигасе я придумал".
Ты хорошо смотрел архитектуру того-же Doctrine? К двери ставиться ровно тот набор ручек который тебе нужен. Зато знаешь что, когда потребуется домофон, дверной глазок, и противопожарная защита, что эти их не проблема поставить и они прекрасно подойдут к твоей двери.
Doctrine - это наиболее проработанный и полный orm фреймворк их всех что я видел под пхп. В тоже время обладающий модульную структурой позволяющий не тащить ВСЮ его функциональность в приложение.

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


Во-первых, существуют разные модели построения библиотек по одной из версий их 9 и в зависимости от модели, разная степень избыточных методов при инициализации.
Во-вторых, benchmark всему голова :D

Пример сценария:

Ты подключаешь "большой" файл, который тащит за собой небольшое кол-во файлов на "все" случаи жизни.
Ты подключаешь "маленький" файл, который представляет из себя "lego", в результате чего, при наращивании функционала, открывается все большее кол-во файлов и плодятся наследуемости\инкапсуляции и прочие шалости ооп.
Класс, обрабатывается целиком перед выполнением, как на ошибки, так на инициализацию расходуется системное время\память.
Подобный Фрейм ворк моя мечта!
Спасибо сделаем все возможное чтобы мечта стала реальностью :-)
Было бы что посмотреть получили бы конструктивную критику и сели бы дописывать свой фреймворк, а так говорить пока не о чем
увидев http://adept-project.com/quickstart/ как-то не захотелось переходить на третий шаг =)

а вообще, интересная штука. только я вроде (!) уже такое видел.
и давно хотел сам писать только влом было :)
НЛО прилетело и опубликовало эту надпись здесь
Ну с этим можно поспорить например парни из 37sugnals говорят обратное. Что касается моделей данных, то у нас есть ORM и мы надеемся его анонсировать в ближайшем будущем.Не все сразу ;-)
НЛО прилетело и опубликовало эту надпись здесь
Веб-приложениями пользуются живые люди (причем различной степени подготовленности) и им глубоко фиолетово до модели данных (а большая их часть вообще не знает что это).

Поверьте, их больше волнует, почему они вынуждены работать со страницами на которых натыкано 10 разных кнопок, и еще 20 полей для ввода. А так бывает, когда программисты сначала создают модель данных, а потом пытаются из того, что получилось выстроить интерфейс взаимодействия с пользователем.

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

Программист должен постоянно держать в голове бизнес-цель разрабатываемого приложения, и как можно меньше отвлекаться на такие вещи, как защита от XSS или на то, почему у него в MSIE не работает javascript-календарь.

Собственно, ребята из 37signals примерно про это и говорят.
Вот о том я и говорю. Я достаточно насмотрелся проектов с красивой схемой хранения и кучей непонятных форм, кнопок и т.д. Пользоваться такими проектами было не возможно
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
По-поводу работы с данными я уже писал выше, что мы разрабатываем ORM, а также не которое количество примочек для бизнес-слоя. Я действительно просто неправильно вас понял извините.
Игорь, расскажите пожалуйста, что это за "модель приложения" на основании которой строится "модель данных".
НЛО прилетело и опубликовало эту надпись здесь
А вот это кто писал:
"основываясь на модели данных, которая в свою очередь основывается на модели приложения, например на UML модели"?
НЛО прилетело и опубликовало эту надпись здесь
Фреймворк этот завут ASP/ASP.Net и существует он сами знаете сколько лет.
Бррр!!! зОвут
Брррр!! ASP. Ну что же, любезнейший, вы нас к мелкомягким в пасть толкаете. Думаю, не стоит даже начинать дискуссию про то, почему я не сторонник решений microsoft, да и зачем вообще мне они требуются.
ждем исходников
захожу на сайт - на всех страницах IE пишет ошибку яваскрипта
НЛО прилетело и опубликовало эту надпись здесь
Делать свои фреймворки нужно и правильно. Без этого сложно стать действительно профессиональным программистом. При разработке фреймворков получается столько граблей и интересных моментов, что после длительной работы над таким проектом - у вас уже появляется довольно широкий кругозор и профессиональный взгляд на код. Вы начинаете понимать - когда стоит писать фреймворки/движки, а когда надо echo "...";.

Путь к созданию фреймворков - путь к универсальности. Но реальные проекты - не требуют такой универсальности. ASP.NET предоставляет сотни свойств для каждого компонента, из которых я использую максимум 5%, а остальная универсальность лишь напрягает процессор и память.

Когда четко известны требования к проекту - его легко выполнить даже обычным PHP/HTML смешением.
Правда я не разу еще не видел проект с четкими требованиями и с условием что ты напишешь раз и забудешь. Всегда приходится что то подправлять изменять. И вот тут то "лапша" показывает себя с очень плохой стороны
см. ответ ниже.
Требования к проекту хороши на бумаге. Потому что когда ты ее читаешь ты точно знаешь что от тебя требуется и как можно достичь этого с минимальными усилиями.

Только вот главное не забывать что когда ты это все напишешь у людей появятся новые желания и новые требования.

Имхо это тоже большая такая грабля которая больно бьет, когда на неё наступаешь
см. ответ ниже.
"Когда четко известны требования к проекту - его легко выполнить даже обычным PHP/HTML смешением."

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

А ведь в 90% случаев от исходных требований к проекту остается маленькая толика...
Стив Макконнел писал "Требования изменчивы". С этим сложно не согласиться.

Но чтобы построить будку собаке не нужен подъемный кран и группа строителей.

Вы должны четко понимать для каких целей ваш фреймворк.

Для упрощения всего и вся? Такое не подойдет. Любая универсальность - усложняет.

Стив Макконнел писал "Боритесь со сложностью".

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

молодцы, поздравляю. интересная система.

хотя я лично для себя выбрал CakePHP, решив не изобретать велосипедов.
Каждому свое
Я просто Зепа очень люблю :-)
НЛО прилетело и опубликовало эту надпись здесь
А Бендер по-вашему профессиональный повар?
Товарищи… эмм… по-моему вы что-то напутали, Бендер это робот. С кукбуком на картинке Зойдберг.
Глупость спорол, пардон.
Объясните, почему глупость? Я согласен с Вашим первым мнением :)
Плачу ) Спасибо Вам: что-то серьёзное объяснить просили, бывало, но ни разу ещё не просили объяснить мою же ошибку ))

Речь в диалоге изначально шла о Бендере, а не о персонаже на картинке. Так что всё правильно )
Да, верно :) Я понял, что мы одинаково запутались :)) Прошу прощения ;)
вроде бы есть похожее - Delphi for PHP
кнопки рисуются, привязываются к ним события и т.п.
Там реализация VCL довольно убогая.
Ну лучше фреймворка с IDE нет ничего в этом случае.. Delphi действительно пыталась что-то сделать, но получилось не очень. Да и стоит это добро почти 3000 баксов.
Не писать фреймворков :) А может ваще ничё не писать. Всё индусы напишут. А ты только копипасть и грепи копейки. Втопку!
Жесть. А какая лицензия?
Мы будем выпускать его под BSD лицензией
Этот фреймворк платный или бесплатный?
Фреймворк бесплатный и с открытыми исходниками. Распространяться будет под BSD лицензией
ммм... Да и в symfony 1.1 тоже на компонентную модель перешли. Не релиз пока еще, но, говорят, вполне юзабельно.
По третьему пункту мама не права. Писать надо. Хотя бы для того чтобы учиться что-то делать.

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

Компонентная модель отправляется на сторону клиента (у меня все необходимые библиотеки требуют загрузки 90кб жаваскрипта), плюс логика, зашитая в модулях, юзающих эти компоненты - загружается по требованию.

Ядро сервера - это 4 core файла, управляющие работой системы и множество datasource/command файлов, реализующих связку клиента с базой данных.
По мне так это просто очередной кривой велосипед. До удобства, скорости, надёжности и универсальности ASP.Net ему не дотянуть никогда.
Создание нового фреймворка - конечно полезный опыт, но иногда просто лучше просто научиться решать задачи эффективным путём.
Задумайтесь над тем фактом, что ваша идея слишком сильно держится на слове "PHP". Убрать его, и решение вашей задачи станет простым, да ещё и будет выбор из нескольких вариантов.
скопировал в блокнот и убрал PHP - проще не стало. Попробовал заменить PHP->ASP, ничего не меняется. Что не так? Почему что-то изменится?
Давайте разработку начнём с пайки схем на лампах. Потому что с лампами я работать умею, а всякие транзисторы - что-то смутное только помню.
>> Мы решили сделать разработку интерфейсной части такой же простой, как и в десктопных приложениях. Мы отказались от классической MVC, заменив ее компонентной архитектурой. То есть, решили создать набор стандартных UI компонентов (кнопки, чекбоксы, радиокнопки, текстовые поля, таблицы), как и в десктопных приложениях, и просто строить интерфейс из этих компонентов.

а чем вам классы форм (в ZF Zend_Form) и хелперы не устроили?
Думаю несколько статей на нашем сайте, которые будут в ближайшие время, снимут подобные вопросы.
Автор, я тебя люблю (not gay). Отличную вещь делаете. Умоляю, не бросайте это.
Спасибо за теплые слова и за поддержку, очень не хватает, особенно когда разрабатываешь opensource проект. Зарегистрируйтесь на сайте или подпишитесь на RSS, нам станет еще приятнее ;-)
Сейчас сделаю.
новый гламурный фреймворк!
посмотрел примеры http://adept-project.com/projects/ большое количество проектов не проходят валидацию html-валидатора, впрочем как и сам http://adept-project.com/. Это конечно занудство и ни в коем случае не умаляет идеи, но валидность компонент вещь необходимая :). Еще я понял, что весь js - свой - как насчет кроссброузерности?
как там у Лебедева было? Лучший валидатор — это браузер. :)

Тем более в разделе "проекты" большая часть сайтов делалась другими командами. Адепт не настолько прекрасен, чтобы еще делать самому валидный HTML. :)

Что касается js — насколько мне известно, тестирование производится минимум в трех браузерах FF, MSIE, Opera. И довольно много времени при разработке компонентов тратится именно на кроссбраузерность. hedin не даст соврать )
Несмотря даже на то что мы используем prototype больше половины времени уходит на борьбу с браузерами. С версткой такая же беда иногда валидный код браузер рендерит не пойми как и наоборот
НЛО прилетело и опубликовало эту надпись здесь
Просто самоирония еще одно отличие нашего фреймворка
SQL инъекция на сайтике av-moskovsky.ru присутствует ;)

SELECT * FROM ms_subcategories WHERE id='
You have an error in your SQL syntax;


как вам доверять-то после этого?
кому нам-то? как писалось выше, не все проекты, выставленные на сайте adept-project.com, делали мы, а делали сторонние разработчики, но используя Adept.
то есть, "не мы", а сторонние разработчики.. пропустил "не" :)
Знаете если программисты не хотят разбираться в модели данных используя row sql, причем подставляя параметры прямо в запрос, то их не спасет никакой фреймворк.
Звучит интересно. Плюс отличный юмор разработчиков :) Желаю удачи, слежу за новостями
Молодцы. А что вы скажете насчет ExtJS? Или я что-то не понимаю и к теме это не относится?
Много букв, и концептуальных моно\диа-логов.

В принципе "+", что изобретаете велосипед, а иначе он никогда не полетит :)
Концепт он как воздух - его можно гонять веками, без сырцов - это не более чем пиар.
Я уже говорил, что сырцы мы выложим в ближайшем времени, так что следите за новостями.
Буду ждать :D
Такой вопрос: А почему бы не использовать 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
Регистрацию начали чинить. Скоро будет готово.

Fatal Error из-за старой версии шаблонов. Скачайте Adept с сайта не версию 0.1.0, а Nightly Build
Спасибо!
Попробую.
Кстати, регистрацию уже починили!
У меня на харде такая платформа валяется уже года два-три. Все очень круто, только я совершил большую ошибку поставив на XML (Хранил в нем лейаут и состояние страницы), а он оказался очень медленным. Вот поэтому и пылится.
что-то пока нормальных и качественных проектов на Adept не наблюдается
минус в карму? ну приведите пример!
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.