Комментарии 40
Ссылку для ленивых и пример в студию!
А где ссылки. Конечно не трудно найти и в гугле, но было-бы удобнее сразу в статье щёлкать.
На Xataface, его вики, форум и доки для быстрого вникания.
На Xataface, его вики, форум и доки для быстрого вникания.
Объясните неучу, почему в качестве интерфейса не подходит phpmyadmin хотя бы. Или интерфейс имеется в виду клиенто-ориентированный?
именно
PhpMyAdmin — это инструментарий для разработчика. Для клиента он мало подходит (что не мешает использовать его при достаточной квалификации), в силу, хотя бы даже, своего чрезмерного функционала и прав доступа.
Другими словами основной момент в клиентском интерфейсе к БД — ограничить права доступа, с тем, чтобы поломать что-либо было максимально затруднительно. В случае с PhpMyAdmin сломать можно многое.
Таким образом, для клиента (секретарь, бухгалтер, любой другой офисный сотрудник), с целью интенсивной работы с данными, при минимальной квалификации, PhpMyAdmin совершенно непригоден.
Другими словами основной момент в клиентском интерфейсе к БД — ограничить права доступа, с тем, чтобы поломать что-либо было максимально затруднительно. В случае с PhpMyAdmin сломать можно многое.
Таким образом, для клиента (секретарь, бухгалтер, любой другой офисный сотрудник), с целью интенсивной работы с данными, при минимальной квалификации, PhpMyAdmin совершенно непригоден.
PhpMyAdmin можно в каком-то смысле ограничить в правах. Для этого просто можно заходить в него под пользователем, у которого заранее ограничены права.
Поправьте, если не прав.
Поправьте, если не прав.
Как Вы себе представляете секретаршу, строчащую MySQL-запросы?
Во-первых, я говорил о том, что при достаточной настройке поломать что-либо можно будет с трудом.
Во-вторых, в PMA можно работать не только SQL-запросами вручную, но и использую пользовательский интерфейс.
Во-вторых, в PMA можно работать не только SQL-запросами вручную, но и использую пользовательский интерфейс.
Поломать практически невозможно, да и работать тоже невозможно пользователю, хоть и SQL писать не обязательно, но они генерируются и выводятся на экран, да и все поля называются латиницей, везде написаны типы полей и другая служебная информация, а пользователю «varchar(64)» или «int(10) unsigned» видеть не обязательно. Ни какой валидации полей, кроме «NOT NULL» и ограничений типа данных — нет, возможностей сделать Master-Detail связки нет. А в прикладном приложении большинство запросов, вообще из нескольких таблиц состоит с JOIN и вложенными запросами, так что цифры, в полях связи пользователю не скажут ничего, нужно будет смотреть, что CityId=35 это Киев, а ClientId=983 это «Вася Пупкин» и потом сколько этих индексов поместится у человека в голове, или он должен подсматривать все время в другие таблицы… В общем PhpMyAdmin нормален только для административных нужд.
Хабраэффект накрыл сайт… По описанию — нереально применимая штука!
скриншотов не хватает
Вот также некоторые аналоги на php:
www.vfront.org
www.dadabik.org
Визуально интерфейс dadabik больше привлек
www.vfront.org
www.dadabik.org
Визуально интерфейс dadabik больше привлек
Идея очень правильная, и системы, генерирующие интерфейсы по метаданным из базы были всегда основой крупных прикладных программ на Clipper, Delphi, C#, Java, а в PHP и вообще в LAMP, или даже шире: веб-приложениях, этого подхода пока очень не хватает. Идеологически это путь очень хороший, но Xataface меня не очень порадовал скудным пользовательским интерфейсом и полным отсутствием юзабилити. Конечно, заполнять таблички контент-менеджеру, «обезьянкам» и девочкам по вводу в нем гораздо проще чем в PhpMyAdmin, но обычному человеку без опыта такого интерфейса не выдашь.
Че-то на Хабре немогу загрузить фото, хочтинг глючит, но вот демо Xataface без логина быстро можете глянуть: www.credituniondb.com/
Собственно это одна из причин, почему я отказался от дальнейшего использования Xataface.
Пока, увы, даже с такими удобными инструментами, как jqGrid, но, всё же, в ручном режиме приходится делать сложные вещи. VFont и dadabik надо будет поизучать. Может там интереснее окажется результат…
Пока, увы, даже с такими удобными инструментами, как jqGrid, но, всё же, в ручном режиме приходится делать сложные вещи. VFont и dadabik надо будет поизучать. Может там интереснее окажется результат…
Я уже глянул их, там интерфейс еще более скупой. Вообще, тема интересная, я все хочу собраться и опубликовать в оупенсорс свой аналог, который выбирает из базы все таблицы, ключи, связи, поля с полными метаданными, после чего модель дополняется еще метеданными, которых в базе нет, и потом генерируюстя интерфейсы и хендлеры для запитывания интерфейсов данными. При чем ограничения доступа и система прав уже есть, единственное, что еще нужно доделать, это возможность навешивать события клиентские (на js) и серверные (на php) на редактирование полей, сохранение, удаление и т.д. Пока все чисто декларативное, но UI для базы из 100 таблиц делается за 2-4 часа. Ищу аналоги чтобы сравнить и подумать, как улучшить.
Ух, круто!
Я когда на клиппере оное делал — то было по молодости и от природной лени, которая, как известно, двигатель чего известно.
В веб-деве проблема в другом — всё настолько бодро и шустро меняется, что пока такой проект увидит свет — он успеет капитально морально устареть, что мы и наблюдаем в случае Xataface. Буквально пару-тройку лет назад, когда он начинался, это был просто писк. Оно и сейчас писк, но морально устаревший.
Я когда на клиппере оное делал — то было по молодости и от природной лени, которая, как известно, двигатель чего известно.
В веб-деве проблема в другом — всё настолько бодро и шустро меняется, что пока такой проект увидит свет — он успеет капитально морально устареть, что мы и наблюдаем в случае Xataface. Буквально пару-тройку лет назад, когда он начинался, это был просто писк. Оно и сейчас писк, но морально устаревший.
Я думаю, что дальше веб начнет развиваться в сторону графики, рендеринга через канвас и svg, видео и звука, мобильных возможностей типа геолокации, WebGL и т.д. А как раз по всем возможностям, которые, нужны для приложений баз данных (DATA AWARE) все уже устаканивается, еще добавили и доделывают реализацию html5 forms с поддержкой кучи плюшек средствами браузеров, и появились еще веб сокеты для синхронизации интерфейса и трансляции серверных событий почти в реальном времени и локальные базы данных в браузерах для кеширования и минимизации трафика и все, что еще нужно… Еще годик и веб будет полностью пригоден для полноценных прикладных приложений, как было на Delphi или C# и как есть на Java, но с доступом из любого браузера, т.к. ставить Java на клиента — не всегда есть хорошо, для джавистов это все тоже полезно, они с удовольствием пересядут на веб-интерфейсы, для своих дорогих приложений корпоративного уровня. Пока они смотрели на браузерный веб сверху вних, как и .NET-чики, собсно. Но даже при устаканенных технологиях нужно будет решать вопрос быстрой разработки. А тут не обойтись без того подхода, о котором Вы подняли тему. Если нужно будет делать приложения на 800 таблиц и 500 экранов, то другой подход совершенно не приемлем. Я называю это «приложения с динамической интерпретацией метеданных» или «динамической интерпретацией метамодели». Это полная противоположность подходу «monkey business», когда каждое изменение поля, таблицы или связи приводит к куче ручной работы по изменению серверной части и интерфейсов, и каждое изменение в интерфейсе приводит к изменению в базе и т.д. Вот конечно имеем мы еще ORM — но это автоматизированный «monkey business», когда все эти этапы есть, но часть работы выполняется программами, это полумеры.
Мне тоже не нравится процесс прегенерации кода. Когда пытался подобрать фреймворк для php+mysql+dhtml+ajax, многие перебрал, многие перещупал. То, что изменения, внесенные после генерации кода, при перегенерации утрачиваются — это ни в какие ворота не лезет. Ну или я не дошел где-то своими мозгами до безболезенных методов перегенерации.
Так сложилось, что решаемые задачи всегда требуют немалой доработки напильником, а всего не упомнишь, и не всегда удается с первого-второго раза сгенерить именно то, что нужно.
В общем в плане обработки данных я как раз склоняюсь в сторону динамической интерпретации метаданных. Движок на клиппере ровно по такому принципу и был построен. Там спасало то, что интерфейс весьма примитивный, и для большинства задач достаточно было универсального построителя форм. Просто допилил штатные инструменты и скомбинировал где надо.
В вебе пока что собственноручная разработка подобного инструмента не оправдывает затрачиваемых на это усилий, но мечта остается. Думаю когда-то она будет реализована в полной мере, чисто из принципа, т.к. у человека, по возможности, не должно оставаться нереализованных мечтаний.
Осталось только найти заказ, требующий именно такого инструментария и имеющий достаточный ресурс для этого.
Так сложилось, что решаемые задачи всегда требуют немалой доработки напильником, а всего не упомнишь, и не всегда удается с первого-второго раза сгенерить именно то, что нужно.
В общем в плане обработки данных я как раз склоняюсь в сторону динамической интерпретации метаданных. Движок на клиппере ровно по такому принципу и был построен. Там спасало то, что интерфейс весьма примитивный, и для большинства задач достаточно было универсального построителя форм. Просто допилил штатные инструменты и скомбинировал где надо.
В вебе пока что собственноручная разработка подобного инструмента не оправдывает затрачиваемых на это усилий, но мечта остается. Думаю когда-то она будет реализована в полной мере, чисто из принципа, т.к. у человека, по возможности, не должно оставаться нереализованных мечтаний.
Осталось только найти заказ, требующий именно такого инструментария и имеющий достаточный ресурс для этого.
Ну с подходящим заказом не должно быть проблем, т.к. почти в любом приложении нужен бек-энд и работа с базами данных. Разве что, в самых простых веб-сайтах этого не нужно, но для них есть класс систем CMS, и там уже много вариантов и все хорошо. А динамическая интерпретация метаданных нужна там, где есть много таблиц, часто меняется предметная область или само изменение предметной области есть нормальный ежедневный функционал системы, или там, где нужно интегрировать разнородные системы.
У меня, кстати, jqGrid используется тоже, но вокруг него очень много всего. По связям можно ходить, например, выбираем в таблице «города» строку и видим связи на таблицы «офисы», «партнеры», «склады» (это связи один-ко-многим, где город один, а этих много) и наоборот, связь к «регионам» как к родительской таблице и к типу города, это например. Можно так гулять вправо и влево по связям, а выбранные строки попадают в фильтр, очень удобно.
У меня, кстати, jqGrid используется тоже, но вокруг него очень много всего. По связям можно ходить, например, выбираем в таблице «города» строку и видим связи на таблицы «офисы», «партнеры», «склады» (это связи один-ко-многим, где город один, а этих много) и наоборот, связь к «регионам» как к родительской таблице и к типу города, это например. Можно так гулять вправо и влево по связям, а выбранные строки попадают в фильтр, очень удобно.
Ну, что называется, в данных связи — это наше всё. :)
Сделать одно, а как подумаю о том, что ко всему этому хозяйству нужно делать документацию, уроки, демо-примеры и видео… но без этого ни как. Пока я даже скриншотов не могу предоставить, т.к. проектов на фреймворке уже более 10 сделано, но данные везде и даже структуры базе не подлежат разглашению, поэтому нужно сделать специально базу 20-30 таблиц совершенно отвлеченную, чтобы на ней все примеры давать.
Опять же, какая нормализация без связей…
То, что изменения, внесенные после генерации кода, при перегенерации утрачиваются — это ни в какие ворота не лезет. Ну или я не дошел где-то своими мозгами до безболезенных методов перегенерации.
Подобная проблема была легко решена в Propel, созданием базовых класов (которые генерятся и которые вручную изменять не стоит) и однократным созданием наследованных классов (которые уже конечный разработчик и правит, и которые не меняются при перегенерации кода).
Думаю, что гораздо логичнее делать переопределения и модификации не в базе данных, не в коде и не в интерфейсах, а в модели, которая компилируется в структуру базы, в код и в интерфейсы. Тогда все, генерируемое автоматически становится лишь временным кешем, сгенерированным лишь для ускорения работы, а источником будет модель предметной области, содержащая как декларативные, так и императивные блоки, из них потом могут быть порождены таблицы, классы, события, методы, формы и т.д.
Да, это тоже решит проблему потери правок в перегенеренном коде. В общем случае решение этой проблемы — не править то, что будет перезаписано при перегенерации.
Насколько я помню, в PHP метапрограммирование очень слабенькое, т.е. задавать модель в виде PHP классов весьма проблематично т.к. трудно будет из них сгенерировать структуру БД и прочие интерфейсы. Хотя могу ошибаться.
Ошибаетесь, метапрограммирование не в PHP слабое, а в PHP очень низкий порог вхождения и много говнокодеров, поэтому примеры хорошего стиля в PHP растворены в море копипаста склеенного на коленке левой пяткой. Задавать модель в виде PHP классов не сложно, там есть все возможности анализировать структуру классов в рантайме. Но после метапрограммирования есть следующий шаг, динамическая интерпретация модели. Для многих ORM модель = классы, для других модель = структуре базы, но что отождествлять модель со звеньями и слоями системы — это частные случаи. Модель предметной области — она вне ООП вообще (ООП лишь средство, в которое можно выгрузить «откомпилированнную» часть текущей версии модели) и вне реляционных СУБД (они лишь предоставляют один из вариантов хранения).
100% ошибаетесь. проверено ведущими собаководами специалистами области
Что-то мне подсказывает, что эта штука что-то на подобии джанговской админки, но только под MySQL…
Для пары внутренних проектов таки начали разработку динамического построителя интерфейсов, на базе конфигов и jqGrid, первые результаты вполне обнадёживающие. В связи с авралами на других проектах (пока в команде не хватает голов и рук), переключились на них. Следующий этап будет разработка динамического построителя смарт-веб-форм на базе конфигов и пока не знаю чего еще. После чего скрестим эти 2 инструмента и получим весьма существенный обхват множества случаев и направлений взаимодействий юзеров с БД. Если всё получится, то разработка с кода сместится в конфиги. :) Эдакое мета-программирование.
Собственно на данный момент мы имеем генератор SQL, умеющий определять, где нужно что заджоинить. Ясно что отработаны не все возможные варианты, а только те, которые нужны были здесь и сейчас.
Так же имеем генератор конфига для jqGrid, и немного JS-кода, который, в частности, позволяет подгружать таблицы справочников в попапе через тот же jqGrid. Всё это благолепие может работать вообще без конфига, сканируя структуру таблиц, разумеется поля должны быть названы в соответствии с соглашением.
Допустим в таблице streets имеем city_id, движок понимает, что здесь идет подключение справочника, в виде таблицы cities, и при попытке отредактировать это поле в строке, вызовет во всплывайке, в отдельном гриде, cities, со всеми его плюшками, а потом подставит id куда надо.
До кучи, для красоты и комфорта, предусмотрена возможность на каждую таблицу подключать 1 или несколько конфигов, которые расширяют стандартное поведение движка, в частности позволяют подключать фантомные поля справочников, которых нет в самой таблице, но которые имеют отношение к таблице через внешние связи, и по ним, в частности, необходимо организовать поиск-сортировку в данной таблице.
Если есть интерес к подобной тематике — пишите в личку.
Так же имеем генератор конфига для jqGrid, и немного JS-кода, который, в частности, позволяет подгружать таблицы справочников в попапе через тот же jqGrid. Всё это благолепие может работать вообще без конфига, сканируя структуру таблиц, разумеется поля должны быть названы в соответствии с соглашением.
Допустим в таблице streets имеем city_id, движок понимает, что здесь идет подключение справочника, в виде таблицы cities, и при попытке отредактировать это поле в строке, вызовет во всплывайке, в отдельном гриде, cities, со всеми его плюшками, а потом подставит id куда надо.
До кучи, для красоты и комфорта, предусмотрена возможность на каждую таблицу подключать 1 или несколько конфигов, которые расширяют стандартное поведение движка, в частности позволяют подключать фантомные поля справочников, которых нет в самой таблице, но которые имеют отношение к таблице через внешние связи, и по ним, в частности, необходимо организовать поиск-сортировку в данной таблице.
Если есть интерес к подобной тематике — пишите в личку.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Первый взгляд на Xataface — систему построения дата-центрированных приложений на PHP и MySQL