Comments 17
Сам подумывал о такой системе. Собственно, ничего сверхестественного в такой задумке нет, половина корпоративных систем имеют такую возможность «из коробки».
UFO just landed and posted this here
Ну во-первых, хранение данных в двух разных таблицах со связью один к одному — моветон. Если это один ко многим, то получаем справочник, реализация которого тоже предполагается(открываете одну таблицу, жмете добавить и в выпадающем списке выбираете нужную сущность из другой таблицы. На крайний случай, можно сделать триггер, который автоматически создаст сущность во второй таблице, если так нужно. Тоже самое с удалением.
Конечно в случае, если у Вас сильно связанная система с жесткими ограничениями, то подобное решение Вам не подойдет.
Предлагаемая мной система рассчитана не на конечных пользователей системы, а скорее для промежуточного персонала: редакторов некоторых табличных данных (например новости на сайте, список сотрудников). Можно подключить такой интерфейс «для себя» чтобы удобно редактировать некоторые данные, не доступные простым пользователям системы, но при этом не хочется писать для себя специальный интерфейс.
Конечно в случае, если у Вас сильно связанная система с жесткими ограничениями, то подобное решение Вам не подойдет.
Предлагаемая мной система рассчитана не на конечных пользователей системы, а скорее для промежуточного персонала: редакторов некоторых табличных данных (например новости на сайте, список сотрудников). Можно подключить такой интерфейс «для себя» чтобы удобно редактировать некоторые данные, не доступные простым пользователям системы, но при этом не хочется писать для себя специальный интерфейс.
UFO just landed and posted this here
Для более сложной логики можно либо не использовать данное решение совсем, либо встроить свой функционал при помощи iframe-ов. Подробнее про это напишу в отдельной статье. Решение с триггером это конечно абсолютный костыль)
Отличие от PHPmyAdmin(помимо универсального решения для различных платформ и БД), это то, что PHPmyAdmin это комплексное сложное решение, предназначенное для разработчика. Он может создавать таблицы, выполнять SQL запросы и прочее. Представьте себе следующую ситуацию:
Есть секретарша Светочка в компании по вязке веников. Начальник Светочки, Виктор, заказал веб-сайт визитку у некой веб-студии Рога&Копыта. На сайте есть раздел новостей и Виктор хочет, чтобы Светочка делилась с миром всем происходящим в мире вязки веников. Разработчики компании Рога&Копыта быстро накидывают дизайн, верстку и заливают на свой любимый хостинг сайт. Но вот делать персональный интерфейс для добавления новостей Светочкой, разработчикам не охота, тем более за это не платят дополнительные деньги. Сами разработчики пользовались PHPmyAdmin, но Светлану обучать не хотят. Тогда они заходят на наш сервис, указывают подключение к БД «Веники», выбирают таблицу News и Светочка получает красивую табличку, в которой есть большая кнопка «добавить» и красненькая кнопка «удалить» и больше её ничего не интересует. Теперь чтобы рассказать миру о новом способе плетения, Светочка просто открывает наш сервис и добавляет новость. Разработчики Рога&Копыта рады что не пришлось писать админки и использовать joomla(тем более, что Виктор что-то говорил о том что со временем хочет многое поменять на сайте, добавить интеграцию с 1С, отчеты в эксель и ворд и много прочих замечательных идей), а Виктор сэкономил немного денег на реализации интерфейса для Светланы.
Да, конечно такой простейший сценарий должен быть бесплатен)
Отличие от PHPmyAdmin(помимо универсального решения для различных платформ и БД), это то, что PHPmyAdmin это комплексное сложное решение, предназначенное для разработчика. Он может создавать таблицы, выполнять SQL запросы и прочее. Представьте себе следующую ситуацию:
Есть секретарша Светочка в компании по вязке веников. Начальник Светочки, Виктор, заказал веб-сайт визитку у некой веб-студии Рога&Копыта. На сайте есть раздел новостей и Виктор хочет, чтобы Светочка делилась с миром всем происходящим в мире вязки веников. Разработчики компании Рога&Копыта быстро накидывают дизайн, верстку и заливают на свой любимый хостинг сайт. Но вот делать персональный интерфейс для добавления новостей Светочкой, разработчикам не охота, тем более за это не платят дополнительные деньги. Сами разработчики пользовались PHPmyAdmin, но Светлану обучать не хотят. Тогда они заходят на наш сервис, указывают подключение к БД «Веники», выбирают таблицу News и Светочка получает красивую табличку, в которой есть большая кнопка «добавить» и красненькая кнопка «удалить» и больше её ничего не интересует. Теперь чтобы рассказать миру о новом способе плетения, Светочка просто открывает наш сервис и добавляет новость. Разработчики Рога&Копыта рады что не пришлось писать админки и использовать joomla(тем более, что Виктор что-то говорил о том что со временем хочет многое поменять на сайте, добавить интеграцию с 1С, отчеты в эксель и ворд и много прочих замечательных идей), а Виктор сэкономил немного денег на реализации интерфейса для Светланы.
Да, конечно такой простейший сценарий должен быть бесплатен)
На мой взгляд идея интересная, и даже готов участвовать в разработке, если пригожусь:)
Хотя есть несколько идей-доплнений:
В идеале, я бы хотел видеть такой сервис:
Теперь, если я залогинился на вашем сайте, то на своем в «editable» div — увижу иконку «редактора». Нажимаю, на месте текста отпрывается красивый редактор, правлю текст, сохраняю, все.
Вот за такой сервис я бы платил… Может есть подобные?
Хотя есть несколько идей-доплнений:
- Как вариант — работать не напрямую с базой, а просто пересылать данные скрипту на стороне клиента. В этом случае нет особых проблем с безопасностью и надежностью — разработчик сам решает в какие таблицы, что и как писать. Но разработчику не нужно разрабатывать админку (интерфейс редактора, загрузчик-редактор картинок и т.п.)
- Запускать редактор в iframe на сайте клиента. Чтобы для редактора все было максимально просто — нажал править текст статьи, и на ее месте появился клевый редактор.
- Кроме текста нужно править и картинки. Грузить их на сервер клиента. Можно еще предлагать облачный хостинг для картинок (м.б. подключить существующий).
- Для популярных CMS нужно сделать профили, чтобы человек мог их подключить в пару кликов, не разбираясь в каких таблицах что хранится.
- На своем сервере есть смысл реализовать резервное копирование всех публикуемых данных (за деньги)
- В качестве доп. услуг есть смысл формировать красивую rss ленту, рассылки новостей, автопостинг в соц сети и т.п. Также можно добавить возможность отложенной публикации новостей.
- Предусмотреть вариант простого подключения, когда сервис даже таблицы для данных создаст сам.
В идеале, я бы хотел видеть такой сервис:
- в любом html-файле одной строчкой подключаю сервис.
- любому div-блоку добавляю класс «editable».
Теперь, если я залогинился на вашем сайте, то на своем в «editable» div — увижу иконку «редактора». Нажимаю, на месте текста отпрывается красивый редактор, правлю текст, сохраняю, все.
Вот за такой сервис я бы платил… Может есть подобные?
1й пункт я планировал для корпоративных пользователей для большей безопасности установка сервиса на стороне клиента, после чего витрина работает с этим сервисом для более быстрой и безопасной пересылки данных
2. думаю вполне возможно, но это далеко не первый этап.
3. по поводу картинок тут конечно отдельный разговор. Проще всего грузить в CDN, чем париться с подключением каталога на стороне клиента. Я думаю что это задача второй очереди(хотя и одна из самых важных)
4. Тоже об этом думал — CMS уже могут содержать метаданные о названиях столбцов и таблиц. Конечно их можно задействовать.
5. Можно, но это больше выглядит как отдельный сервис.
6. Это все относится к уже к реализации самого сайта, думаю тут не стоит загоняться, иначе получится CMS)
7. Для англоязычных пользователей в идеале названия полей и таблиц будут совпадать, да. Но могут быть служебные таблицы, не нужные для отображения или таблицы со списком пользователей, связи со справочниками. Все равно что-то нужно будет настраивать.
А по поводу аналогов вообще загадочно — на данный момент 8 человек проголосовало за то, что это велосипед, но ни один не привел ссылку на существующие решения в этой области.
2. думаю вполне возможно, но это далеко не первый этап.
3. по поводу картинок тут конечно отдельный разговор. Проще всего грузить в CDN, чем париться с подключением каталога на стороне клиента. Я думаю что это задача второй очереди(хотя и одна из самых важных)
4. Тоже об этом думал — CMS уже могут содержать метаданные о названиях столбцов и таблиц. Конечно их можно задействовать.
5. Можно, но это больше выглядит как отдельный сервис.
6. Это все относится к уже к реализации самого сайта, думаю тут не стоит загоняться, иначе получится CMS)
7. Для англоязычных пользователей в идеале названия полей и таблиц будут совпадать, да. Но могут быть служебные таблицы, не нужные для отображения или таблицы со списком пользователей, связи со справочниками. Все равно что-то нужно будет настраивать.
А по поводу аналогов вообще загадочно — на данный момент 8 человек проголосовало за то, что это велосипед, но ни один не привел ссылку на существующие решения в этой области.
1. разворачивать систему на сервере у клиента, имхо, не целесообразно. Получается некая недоCMS. По моему лучше передавать данные простым запросом POST (можно шифровать паролем). А разработчик сайта уже сам определит куда данные записать (можно ему давать стандартный обработчик, так чтобы только имена таблиц нужно было поменять в коде и все). Так получится гибче и безопаснее.
2. А по моему это как раз важно. Т.к. очень неудобно (а главное, непривычно) набирать пост на одном сайте, а смотреть на другом. А если картинки поплывут? А если шрифты поменять захочется? Так и скакать-туда сюда? Заказчик это точно воспримет как недостаток и непрофессионализм разработчика…
3. без картинок система (имхо) нежизнеспособна.
5. скорее как конкурентное преимущество
6. Напротив, если ваш сервис возьмет на себя весь функционал обновления контента, а сам сайт будет только «витриной» — то получится адекватное «разделение труда». А если половину нужного функционала нужно все равно самому писать — то проще вообще отказаться от сервиса.
По сути, у вас получается визуальный редактор (а их множество, в т.ч. бесплатных) + запись в базу, что реализуется в несколько строк. В таком виде сервис мало кому пригодиться.
7-й пункт относился к тому что я написал дальше, насчет «идеального» для меня варианта.
Т.е. пользователь может залить на бесплатный хостинг html страничку, (м.б. даже не имея ни php, ни базы данных). Потом в одну строку подключает сервис и превращает страничку в личный блог…
Что-то типа виджетов комментариев от социальных сетей, только для администраторов сайтов.
Понятно, что потом можно завести свою базу, автоматом перенести туда данные, но это если сайт будет развиваться. Часто это и не нужно совсем.
2. А по моему это как раз важно. Т.к. очень неудобно (а главное, непривычно) набирать пост на одном сайте, а смотреть на другом. А если картинки поплывут? А если шрифты поменять захочется? Так и скакать-туда сюда? Заказчик это точно воспримет как недостаток и непрофессионализм разработчика…
3. без картинок система (имхо) нежизнеспособна.
5. скорее как конкурентное преимущество
6. Напротив, если ваш сервис возьмет на себя весь функционал обновления контента, а сам сайт будет только «витриной» — то получится адекватное «разделение труда». А если половину нужного функционала нужно все равно самому писать — то проще вообще отказаться от сервиса.
По сути, у вас получается визуальный редактор (а их множество, в т.ч. бесплатных) + запись в базу, что реализуется в несколько строк. В таком виде сервис мало кому пригодиться.
7-й пункт относился к тому что я написал дальше, насчет «идеального» для меня варианта.
Т.е. пользователь может залить на бесплатный хостинг html страничку, (м.б. даже не имея ни php, ни базы данных). Потом в одну строку подключает сервис и превращает страничку в личный блог…
Что-то типа виджетов комментариев от социальных сетей, только для администраторов сайтов.
Понятно, что потом можно завести свою базу, автоматом перенести туда данные, но это если сайт будет развиваться. Часто это и не нужно совсем.
1. Я говорю не об установке полноценного сервиса, а о небольшом посреднике, чтобы данные пересылались только внутри подсети клиента. Кроме того, подчеркну, что я предполагаю наличие базы данных именно на стороне клиента. Решение, где база данных и её красивый редактор поставляются в качестве сервиса, я видел и мне кажется оно сложно и уныло.
2. Ну у всех браузеров, к счастью, есть механизм вкладок, так что скакать туда сюда довольно просто. Если же вешать обработчики на статьи прямо на сайте, то разработчикам сайта необходимо будет заморачиваться с авторизацией, чтобы эти обработчики отображались только у определенных людей.
3. Согласен. Просто у меня есть определенный план действий и приоритеты. Все сразу все равно не сделаешь, так что загрузчик файлов отходит на второй этап. Для начала нужно изготовить какой-то бесплатный сильно ограниченный прототип.
6. Я почитал Вашу статью про конструктор сайтов из статичных страниц. Идея конечно интересная, но это опять же CMS, я же хочу идти по пути именно визуального редактора БД, но которым сможет пользоваться секретарша Светочка, котораю любит сидеть в одноклассниках, но делает огромные глаза, когда слышит SQL. Буду благодарен, если скинете ссылку на такой удобный и доступный редактор.
7. Это опять же Ваша идея с CMS. Тогда можно совсем отказаться и от поиска клиентом хостинга, а предоставлять и эти статичные странички. Это получается некогда популярный конструктор сайтов на narod.ru. Я же просто хочу облегчить разработчикам жизнь в части создания админок для простых смертных.
2. Ну у всех браузеров, к счастью, есть механизм вкладок, так что скакать туда сюда довольно просто. Если же вешать обработчики на статьи прямо на сайте, то разработчикам сайта необходимо будет заморачиваться с авторизацией, чтобы эти обработчики отображались только у определенных людей.
3. Согласен. Просто у меня есть определенный план действий и приоритеты. Все сразу все равно не сделаешь, так что загрузчик файлов отходит на второй этап. Для начала нужно изготовить какой-то бесплатный сильно ограниченный прототип.
6. Я почитал Вашу статью про конструктор сайтов из статичных страниц. Идея конечно интересная, но это опять же CMS, я же хочу идти по пути именно визуального редактора БД, но которым сможет пользоваться секретарша Светочка, котораю любит сидеть в одноклассниках, но делает огромные глаза, когда слышит SQL. Буду благодарен, если скинете ссылку на такой удобный и доступный редактор.
7. Это опять же Ваша идея с CMS. Тогда можно совсем отказаться и от поиска клиентом хостинга, а предоставлять и эти статичные странички. Это получается некогда популярный конструктор сайтов на narod.ru. Я же просто хочу облегчить разработчикам жизнь в части создания админок для простых смертных.
Если вы просто хотите облегчить жизнь разработчикам, чтоб им не приходилось под каждый проект делать админку к БД (хотя почему то мне кажется у большинства разрабов уже есть свои тиражируемые решения), то зачем обворачивать все это в некий сервис, до кучи в облаках? Пишите, выкладывайте в open-source, те кому подойдёт будут пользоваться, другие будут под себя допиливать, третьи форкнут и сделают более крутой аналог и будет всем хорошо. Денег вы на этом все равно не заработает, так что open-source + self-hosting это имхо ваш путь.
Я все же нашел ребят, которые сделали такой сервис и, по всей видимости, они весьма успешно зарабатывают на нем.
По поводу выкладывания в open-source, во-первых теряется независимость от платформы. Во-вторых, потребуются ресурсы для разворота сервиса.
Я думаю, что для open-source проектов можно будет дать бесплатный доступ + сделать немного урезанную бесплатную версию для стартапов.
По поводу выкладывания в open-source, во-первых теряется независимость от платформы. Во-вторых, потребуются ресурсы для разворота сервиса.
Я думаю, что для open-source проектов можно будет дать бесплатный доступ + сделать немного урезанную бесплатную версию для стартапов.
Дайте плиз ссылочку на этих ребят, интересно посмотреть.
Насчёт open-source, не вижу никаких проблем. Не понял зачем мне независимость от платформы и никаких проблем не должно возникнуть у разработчиков, чтобы развернуть ваш open-source soft у себя.
Сдаётся, что вы просто хотите заработать денег на этом, что в принципе понятно и правильно. Однако имхо это не тот проект. Слишком мало ценности вы предлагаете и при этом слишком много простое в замен (деньги, доступ к БД и т.п.). Мне кажется, даже если поставить цель именно заработать, то open-source и в этом случае подойдет. Поддержку, деплой и кастумизацию open-source софта ещё никто не отменял.
Насчёт open-source, не вижу никаких проблем. Не понял зачем мне независимость от платформы и никаких проблем не должно возникнуть у разработчиков, чтобы развернуть ваш open-source soft у себя.
Сдаётся, что вы просто хотите заработать денег на этом, что в принципе понятно и правильно. Однако имхо это не тот проект. Слишком мало ценности вы предлагаете и при этом слишком много простое в замен (деньги, доступ к БД и т.п.). Мне кажется, даже если поставить цель именно заработать, то open-source и в этом случае подойдет. Поддержку, деплой и кастумизацию open-source софта ещё никто не отменял.
ошибся веткой
UFO just landed and posted this here
Sign up to leave a comment.
Облачная система управления контентом базы данных