Первый взгляд на Xataface — систему построения дата-центрированных приложений на PHP и MySQL

Приветствую многоуважаемых хабражителей.

Поиск по Хабру по ключевым словам «dataface» и «xataface» привёл к пустой странице результатов, поэтому считаю своим долгом поделиться с честной публикой своим давним открытием, до сей поры остававшимся в тени.

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

Подробности под катом.

Начиналось всё просто. Мне поступил очередной заказ на разработку удобного интерфейса к базе данных. Почитав «ТЗ» я пришел к выводу, что за предложенный бюджет столько работать не хочется. В то же время всплыла в памяти давняя идея, как скрестить лень с изобретательностью, и таки попробовать построить умную систему, которой скормил данные, оформил связи, а она сама строит остальное.

Скажу честно, нечто подобное я уже делал, но под DOS/Clipper 5.2, где это замечательно работает и по сей день, порядка 8 лет. Но PHP+HTML+CSS+JS+AJAX — это несколько более заморочная тема со своими нюансами и моментами.

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

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

И случилось чудо. Я нашел нечто, что отдаленно напоминало то, что мне было так необходимо. Сайт некоего Стива Ханны (Steve Hannah) разработчика веб-служб на факультете прикладных наук в Simon Frazer University.

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

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

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

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

Тем не менее, впечатление о системе в целом, и подходе, в частности, положительные. Система делает ровно то, что заявлено, ровно так, как заявлено. Более того, система постоянно развивается, появляются патчи, фиксы, новые версии.

Присутствует довольно обширная документация в формате Wiki, форум, где автор активно общается с пользователями системы, даже пару видеороликов, из разряда «How to».

Разумеется всё на английском, как я писал выше, рунет о данной системе ничего не знает.

Система написана в стиле ООП на PHP, с использованием MySQL, шаблонизатора Smarty, MVC, и т.п. Формы и таблицы генерятся автоматом, конфиги хранятся в классических .ini файлах, всё довольно прозрачно и хорошо структурировано. Поддерживаются плагины и пользовательские расширения. Присутствует система авторизации-аутентификации, контроль доступа, из коробки.

Xataface — не идеальное воплощение того, что я хотел бы получить в перспективе, однако вполне работоспособное.

Желаю приятного ознакомления с этой оригинальной новинкой.

P.S.: Заказ был выполнен при помощи Xataface, в срок и в рамках выделенного бюджета. И да, напильником поработать пришлось, в частности при построении отчетов и выгрузок. Впечатления остались весьма приятные, но в следующих проектах я предпочел использовать jqGrid и ручной выделки формы с массой интерактивных элементов и сложной логикой, и много-много AJAX'a, но это уже совершенно отдельная история.

P.P.S.: По просьбам трудящихся (хабрачеловек 4dmonster) ссылки:
Поделиться публикацией

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

    +2
    Ссылку для ленивых и пример в студию!
      +6
      А где ссылки. Конечно не трудно найти и в гугле, но было-бы удобнее сразу в статье щёлкать.
      На Xataface, его вики, форум и доки для быстрого вникания.
        +1
        А что какаемо сабжа — удобная штука для своей ниши.
          +4
          Да какаемый сабж — удобная штука:)
          +1
          Заапдейтил топик. Мерси.
          0
          Объясните неучу, почему в качестве интерфейса не подходит phpmyadmin хотя бы. Или интерфейс имеется в виду клиенто-ориентированный?
            +1
            именно
              +1
              PhpMyAdmin — это инструментарий для разработчика. Для клиента он мало подходит (что не мешает использовать его при достаточной квалификации), в силу, хотя бы даже, своего чрезмерного функционала и прав доступа.

              Другими словами основной момент в клиентском интерфейсе к БД — ограничить права доступа, с тем, чтобы поломать что-либо было максимально затруднительно. В случае с PhpMyAdmin сломать можно многое.

              Таким образом, для клиента (секретарь, бухгалтер, любой другой офисный сотрудник), с целью интенсивной работы с данными, при минимальной квалификации, PhpMyAdmin совершенно непригоден.
                +1
                PhpMyAdmin можно в каком-то смысле ограничить в правах. Для этого просто можно заходить в него под пользователем, у которого заранее ограничены права.
                Поправьте, если не прав.
                  +2
                  Как Вы себе представляете секретаршу, строчащую MySQL-запросы?
                    0
                    Во-первых, я говорил о том, что при достаточной настройке поломать что-либо можно будет с трудом.
                    Во-вторых, в PMA можно работать не только SQL-запросами вручную, но и использую пользовательский интерфейс.
                      +1
                      Поломать практически невозможно, да и работать тоже невозможно пользователю, хоть и SQL писать не обязательно, но они генерируются и выводятся на экран, да и все поля называются латиницей, везде написаны типы полей и другая служебная информация, а пользователю «varchar(64)» или «int(10) unsigned» видеть не обязательно. Ни какой валидации полей, кроме «NOT NULL» и ограничений типа данных — нет, возможностей сделать Master-Detail связки нет. А в прикладном приложении большинство запросов, вообще из нескольких таблиц состоит с JOIN и вложенными запросами, так что цифры, в полях связи пользователю не скажут ничего, нужно будет смотреть, что CityId=35 это Киев, а ClientId=983 это «Вася Пупкин» и потом сколько этих индексов поместится у человека в голове, или он должен подсматривать все время в другие таблицы… В общем PhpMyAdmin нормален только для административных нужд.
              0
              Хабраэффект накрыл сайт… По описанию — нереально применимая штука!
                +1
                скриншотов не хватает
                  +4
                  Будет продолжение, более подробное, с нюансами и деталями.
                  0
                  Вот также некоторые аналоги на php:
                  www.vfront.org
                  www.dadabik.org

                  Визуально интерфейс dadabik больше привлек
                    0
                    Идея очень правильная, и системы, генерирующие интерфейсы по метаданным из базы были всегда основой крупных прикладных программ на Clipper, Delphi, C#, Java, а в PHP и вообще в LAMP, или даже шире: веб-приложениях, этого подхода пока очень не хватает. Идеологически это путь очень хороший, но Xataface меня не очень порадовал скудным пользовательским интерфейсом и полным отсутствием юзабилити. Конечно, заполнять таблички контент-менеджеру, «обезьянкам» и девочкам по вводу в нем гораздо проще чем в PhpMyAdmin, но обычному человеку без опыта такого интерфейса не выдашь.
                      0
                      Че-то на Хабре немогу загрузить фото, хочтинг глючит, но вот демо Xataface без логина быстро можете глянуть: www.credituniondb.com/
                        +1
                        Собственно это одна из причин, почему я отказался от дальнейшего использования Xataface.

                        Пока, увы, даже с такими удобными инструментами, как jqGrid, но, всё же, в ручном режиме приходится делать сложные вещи. VFont и dadabik надо будет поизучать. Может там интереснее окажется результат…
                          0
                          Я уже глянул их, там интерфейс еще более скупой. Вообще, тема интересная, я все хочу собраться и опубликовать в оупенсорс свой аналог, который выбирает из базы все таблицы, ключи, связи, поля с полными метаданными, после чего модель дополняется еще метеданными, которых в базе нет, и потом генерируюстя интерфейсы и хендлеры для запитывания интерфейсов данными. При чем ограничения доступа и система прав уже есть, единственное, что еще нужно доделать, это возможность навешивать события клиентские (на js) и серверные (на php) на редактирование полей, сохранение, удаление и т.д. Пока все чисто декларативное, но UI для базы из 100 таблиц делается за 2-4 часа. Ищу аналоги чтобы сравнить и подумать, как улучшить.
                            0
                            Ух, круто!

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

                            В веб-деве проблема в другом — всё настолько бодро и шустро меняется, что пока такой проект увидит свет — он успеет капитально морально устареть, что мы и наблюдаем в случае Xataface. Буквально пару-тройку лет назад, когда он начинался, это был просто писк. Оно и сейчас писк, но морально устаревший.
                              +1
                              Я думаю, что дальше веб начнет развиваться в сторону графики, рендеринга через канвас и svg, видео и звука, мобильных возможностей типа геолокации, WebGL и т.д. А как раз по всем возможностям, которые, нужны для приложений баз данных (DATA AWARE) все уже устаканивается, еще добавили и доделывают реализацию html5 forms с поддержкой кучи плюшек средствами браузеров, и появились еще веб сокеты для синхронизации интерфейса и трансляции серверных событий почти в реальном времени и локальные базы данных в браузерах для кеширования и минимизации трафика и все, что еще нужно… Еще годик и веб будет полностью пригоден для полноценных прикладных приложений, как было на Delphi или C# и как есть на Java, но с доступом из любого браузера, т.к. ставить Java на клиента — не всегда есть хорошо, для джавистов это все тоже полезно, они с удовольствием пересядут на веб-интерфейсы, для своих дорогих приложений корпоративного уровня. Пока они смотрели на браузерный веб сверху вних, как и .NET-чики, собсно. Но даже при устаканенных технологиях нужно будет решать вопрос быстрой разработки. А тут не обойтись без того подхода, о котором Вы подняли тему. Если нужно будет делать приложения на 800 таблиц и 500 экранов, то другой подход совершенно не приемлем. Я называю это «приложения с динамической интерпретацией метеданных» или «динамической интерпретацией метамодели». Это полная противоположность подходу «monkey business», когда каждое изменение поля, таблицы или связи приводит к куче ручной работы по изменению серверной части и интерфейсов, и каждое изменение в интерфейсе приводит к изменению в базе и т.д. Вот конечно имеем мы еще ORM — но это автоматизированный «monkey business», когда все эти этапы есть, но часть работы выполняется программами, это полумеры.
                                +2
                                Мне тоже не нравится процесс прегенерации кода. Когда пытался подобрать фреймворк для php+mysql+dhtml+ajax, многие перебрал, многие перещупал. То, что изменения, внесенные после генерации кода, при перегенерации утрачиваются — это ни в какие ворота не лезет. Ну или я не дошел где-то своими мозгами до безболезенных методов перегенерации.

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

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

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

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

                                  У меня, кстати, jqGrid используется тоже, но вокруг него очень много всего. По связям можно ходить, например, выбираем в таблице «города» строку и видим связи на таблицы «офисы», «партнеры», «склады» (это связи один-ко-многим, где город один, а этих много) и наоборот, связь к «регионам» как к родительской таблице и к типу города, это например. Можно так гулять вправо и влево по связям, а выбранные строки попадают в фильтр, очень удобно.
                                    0
                                    Ну, что называется, в данных связи — это наше всё. :)
                                      0
                                      Сделать одно, а как подумаю о том, что ко всему этому хозяйству нужно делать документацию, уроки, демо-примеры и видео… но без этого ни как. Пока я даже скриншотов не могу предоставить, т.к. проектов на фреймворке уже более 10 сделано, но данные везде и даже структуры базе не подлежат разглашению, поэтому нужно сделать специально базу 20-30 таблиц совершенно отвлеченную, чтобы на ней все примеры давать.
                                        0
                                        Собственно говоря сходная ситуация. Чтобы продемонстрировать нечто — часто приходится ваять на его базе dummy.
                                      0
                                      Опять же, какая нормализация без связей…
                                      0
                                      То, что изменения, внесенные после генерации кода, при перегенерации утрачиваются — это ни в какие ворота не лезет. Ну или я не дошел где-то своими мозгами до безболезенных методов перегенерации.

                                      Подобная проблема была легко решена в Propel, созданием базовых класов (которые генерятся и которые вручную изменять не стоит) и однократным созданием наследованных классов (которые уже конечный разработчик и правит, и которые не меняются при перегенерации кода).
                                        0
                                        Думаю, что гораздо логичнее делать переопределения и модификации не в базе данных, не в коде и не в интерфейсах, а в модели, которая компилируется в структуру базы, в код и в интерфейсы. Тогда все, генерируемое автоматически становится лишь временным кешем, сгенерированным лишь для ускорения работы, а источником будет модель предметной области, содержащая как декларативные, так и императивные блоки, из них потом могут быть порождены таблицы, классы, события, методы, формы и т.д.
                                          0
                                          Да, это тоже решит проблему потери правок в перегенеренном коде. В общем случае решение этой проблемы — не править то, что будет перезаписано при перегенерации.
                                            0
                                            Насколько я помню, в PHP метапрограммирование очень слабенькое, т.е. задавать модель в виде PHP классов весьма проблематично т.к. трудно будет из них сгенерировать структуру БД и прочие интерфейсы. Хотя могу ошибаться.
                                              +1
                                              Ошибаетесь, метапрограммирование не в PHP слабое, а в PHP очень низкий порог вхождения и много говнокодеров, поэтому примеры хорошего стиля в PHP растворены в море копипаста склеенного на коленке левой пяткой. Задавать модель в виде PHP классов не сложно, там есть все возможности анализировать структуру классов в рантайме. Но после метапрограммирования есть следующий шаг, динамическая интерпретация модели. Для многих ORM модель = классы, для других модель = структуре базы, но что отождествлять модель со звеньями и слоями системы — это частные случаи. Модель предметной области — она вне ООП вообще (ООП лишь средство, в которое можно выгрузить «откомпилированнную» часть текущей версии модели) и вне реляционных СУБД (они лишь предоставляют один из вариантов хранения).
                                                0
                                                100% ошибаетесь. проверено ведущими собаководами специалистами области
                                0
                                Что-то мне подсказывает, что эта штука что-то на подобии джанговской админки, но только под MySQL…
                                  +1
                                  Да, это похожая штука, но попроще. Если есть еще альтернативы — присылайте ссылки, хочется ознакомиться с альтернативами, чтобы выделить хорошие мысли.
                                    0
                                    Поддерживаю.
                                  +1
                                  Для пары внутренних проектов таки начали разработку динамического построителя интерфейсов, на базе конфигов и jqGrid, первые результаты вполне обнадёживающие. В связи с авралами на других проектах (пока в команде не хватает голов и рук), переключились на них. Следующий этап будет разработка динамического построителя смарт-веб-форм на базе конфигов и пока не знаю чего еще. После чего скрестим эти 2 инструмента и получим весьма существенный обхват множества случаев и направлений взаимодействий юзеров с БД. Если всё получится, то разработка с кода сместится в конфиги. :) Эдакое мета-программирование.
                                    0
                                    Могу поделиться исходниками, у меня уже кое-что работающее с гридами и формами, можем объединить усилия.
                                    0
                                    Собственно на данный момент мы имеем генератор SQL, умеющий определять, где нужно что заджоинить. Ясно что отработаны не все возможные варианты, а только те, которые нужны были здесь и сейчас.

                                    Так же имеем генератор конфига для jqGrid, и немного JS-кода, который, в частности, позволяет подгружать таблицы справочников в попапе через тот же jqGrid. Всё это благолепие может работать вообще без конфига, сканируя структуру таблиц, разумеется поля должны быть названы в соответствии с соглашением.

                                    Допустим в таблице streets имеем city_id, движок понимает, что здесь идет подключение справочника, в виде таблицы cities, и при попытке отредактировать это поле в строке, вызовет во всплывайке, в отдельном гриде, cities, со всеми его плюшками, а потом подставит id куда надо.

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

                                    Если есть интерес к подобной тематике — пишите в личку.

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

                                    Самое читаемое