В этой теме принимаем заявки от разработчиков (конфигураторов) на тему, что нужно, чтобы с программу Клиентская база можно было легко использовать самостоятельно для разработки любых конфигураций и выполнения заказов по разработке автоматизированных систем.
Очевидно что необходимо:
1. Описание структуры базы данных MySQL. Описание таблиц и полей для понимания как хранятся данные.
2. Примеры работы с вычисляемыми полями (постоянно пополняемый раздел).
3. Документация по встроенным функциям
4. Возможность присоединения к программе собственных скриптов для работы со сторонними базами данных и так далее.
Вышеописанные пункты постараемся выполнить к концу января 2010 года.
Чего еще хотелось бы? Пишите - обсудим.
1
Чего хотят разработчики?
Автор Гарифуллин Марат, 23 дек. 2009 11:36
Сообщений в теме: 6
#2
-
- Пользователи
-
- 145 сообщений
Активный участник
Отправлено 26 Декабрь 2009 - 09:45
Добрый день,
У Вас замечательная система, и одно из ее преимуществ - простота.
Простой интерфейс и простая структура - это Ваши дифференцирующие преимущества и лучше их не терять.
Лично мне не хватает:
1. Документации (я понимаю, что пока система активно разрабатывается, то документация будет быстро устаревать) - поэтому, очень хочется увидеть CHANGELOG, в котором бы разработчики отражали все изменения - что пофиксили, что изменили, что добавили и что не работает.
2. Динамического связывания полей в формах ввода (редактирования) записей - т.е. той функции, которая у Вас реализована в режиме создания/редактирования полей, т.е. когда вначале выбираешь тип поля, а последующие поля меняют тип/значение в зависимости от значения предыдущего поля.
Можно еще много чего написать, типа
отдельного движка для поиска, чтоб даже по 2-3 символам подстроки находил нужные поля во всей базе данных в режиме реального времени,
добавить поддержку Google WebSocket
полную историю изменений по каждой записи
....
.... но все это не нужно, так как помешает Вам сосредоточить свои усилия на более важных вещах.
Для разработки решений для малого и среднего бизнеса в первую очередь нужна простота - как простота разработки, так и простота интерфейса (логики работы системы). Не нужно усложнять систему...
Есть желание взять очень интересные возможности из таких систем как http://dabbledb.com/ http://aribaweb.org/ http://www.zentrack.net/ но не зря же говорят - «Не следует умножать сущности сверх необходимого»
)
У Вас замечательная система, и одно из ее преимуществ - простота.
Простой интерфейс и простая структура - это Ваши дифференцирующие преимущества и лучше их не терять.
Лично мне не хватает:
1. Документации (я понимаю, что пока система активно разрабатывается, то документация будет быстро устаревать) - поэтому, очень хочется увидеть CHANGELOG, в котором бы разработчики отражали все изменения - что пофиксили, что изменили, что добавили и что не работает.
2. Динамического связывания полей в формах ввода (редактирования) записей - т.е. той функции, которая у Вас реализована в режиме создания/редактирования полей, т.е. когда вначале выбираешь тип поля, а последующие поля меняют тип/значение в зависимости от значения предыдущего поля.
Можно еще много чего написать, типа
отдельного движка для поиска, чтоб даже по 2-3 символам подстроки находил нужные поля во всей базе данных в режиме реального времени,
добавить поддержку Google WebSocket
полную историю изменений по каждой записи
....
.... но все это не нужно, так как помешает Вам сосредоточить свои усилия на более важных вещах.
Для разработки решений для малого и среднего бизнеса в первую очередь нужна простота - как простота разработки, так и простота интерфейса (логики работы системы). Не нужно усложнять систему...
Есть желание взять очень интересные возможности из таких систем как http://dabbledb.com/ http://aribaweb.org/ http://www.zentrack.net/ но не зря же говорят - «Не следует умножать сущности сверх необходимого»
)
#3
-
- Пользователи
-
- 10 сообщений
Участник
Отправлено 20 Февраль 2010 - 23:00
Разработчик №2 (23.12.2009, 11:36) писал:
В этой теме принимаем заявки от разработчиков (конфигураторов) на тему, что нужно, чтобы с программу Клиентская база можно было легко использовать самостоятельно для разработки любых конфигураций и выполнения заказов по разработке автоматизированных систем.
Очевидно что необходимо:
1. Описание структуры базы данных MySQL. Описание таблиц и полей для понимания как хранятся данные.
2. Примеры работы с вычисляемыми полями (постоянно пополняемый раздел).
3. Документация по встроенным функциям
4. Возможность присоединения к программе собственных скриптов для работы со сторонними базами данных и так далее.
Вышеописанные пункты постараемся выполнить к концу января 2010 года.
Чего еще хотелось бы? Пишите - обсудим.
Очевидно что необходимо:
1. Описание структуры базы данных MySQL. Описание таблиц и полей для понимания как хранятся данные.
2. Примеры работы с вычисляемыми полями (постоянно пополняемый раздел).
3. Документация по встроенным функциям
4. Возможность присоединения к программе собственных скриптов для работы со сторонними базами данных и так далее.
Вышеописанные пункты постараемся выполнить к концу января 2010 года.
Чего еще хотелось бы? Пишите - обсудим.
Хорошая тема, как раз выбираю продукт который будет гибко расширяться. Все что вы написали - очень нужно.
Особенно последний пункт. Есть заинтересованность в расширении собственными скриптами внутри "базы" в виде доп.разделов. Хотелось бы иметь функционал альтернативной авторизации (+ своя таблица юзеров), чтобы можно было "базу" внедрять в другие проекты.
Еще хорошо было бы у компаний и событий назначать таблицу вручную (указывать имя в базе), чтобы также можно было интегрировать в другие проекты, т.е. управлять базой клиентов через свою CMS.
Ну и напоследок не хватает открытого кода, чтобы знать что происходит внутри при тех же ошибках (может быть при подписании бумажного партнерского договора?)
#4
-
- Пользователи
-
- 20 сообщений
Участник
Отправлено 19 Март 2010 - 23:12
Объясните мне такую явную необходимость использования smarty. Кроме кеширования и хранения в файлах и русскоязычных переменных.
Весь функционал smarty фактически, так или иначе дублирует функционал PHP. Подготовка данных происходит с использованием PHP, а уже после этого происходит $this->assign($foo, "bar");
Для чего разработчику дополнительный язык (smarty) когда все тоже можно с успехом реализовать на PHP.
Шаблоны можно так же хранить в базе или в файлах вместе с самим PHP-кодом. Хотя, конечно, мне никто не запрещает просто использовать {PHP} {/PHP}. Но мне просто интересно.
Еще было бы гораздо удобней если бы таблицы назывались ассоциативно, а не по ID, так же как и поля внутри них. Может быть это реализовать простой транслитерацией? А ID полей и таблиц реализовать через дополнительную строку, например, feildID где в каждом поле будет стоять его уникальный индекс. Функционально система практически ничего не теряет, за исключением необходимых в связи с этим изменений, а вот понятность и наглядность БД, связей и главное кода увеличится неимоверно. Сейчас же приходится искать поля по таблицам и смотреть какого характера там данные, и уже по данным определять, что это за связь (я про связи в коде, а не в системе).
Весь функционал smarty фактически, так или иначе дублирует функционал PHP. Подготовка данных происходит с использованием PHP, а уже после этого происходит $this->assign($foo, "bar");
Для чего разработчику дополнительный язык (smarty) когда все тоже можно с успехом реализовать на PHP.
Шаблоны можно так же хранить в базе или в файлах вместе с самим PHP-кодом. Хотя, конечно, мне никто не запрещает просто использовать {PHP} {/PHP}. Но мне просто интересно.
Еще было бы гораздо удобней если бы таблицы назывались ассоциативно, а не по ID, так же как и поля внутри них. Может быть это реализовать простой транслитерацией? А ID полей и таблиц реализовать через дополнительную строку, например, feildID где в каждом поле будет стоять его уникальный индекс. Функционально система практически ничего не теряет, за исключением необходимых в связи с этим изменений, а вот понятность и наглядность БД, связей и главное кода увеличится неимоверно. Сейчас же приходится искать поля по таблицам и смотреть какого характера там данные, и уже по данным определять, что это за связь (я про связи в коде, а не в системе).
#5
-
- Программист ООО "КБ"
-
- 8 761 сообщений
Активный участник
- Пол:Мужчина
- Город:Казань
Отправлено 21 Март 2010 - 17:30
Nik (19.3.2010, 23:12) писал:
Объясните мне такую явную необходимость использования smarty.
Nik (19.3.2010, 23:12) писал:
Еще было бы гораздо удобней если бы таблицы назывались ассоциативно, а не по ID, так же как и поля внутри них. Может быть это реализовать простой транслитерацией?
Упрощение нами реализуется иначе - путем создания функций для работы с БД, где можно задавать напрямую кириллические имена таблиц и полей.
#6
-
- Пользователи
-
- 20 сообщений
Участник
Отправлено 22 Март 2010 - 17:19
Про смарти понятно.
Про имена и индексы я писал, что можно сделать (достаточно просто) полную обратную-совместимость кода. Но раз уж решение разрабатывается, смысла, что-то доказывать тоже нет.
Про имена и индексы я писал, что можно сделать (достаточно просто) полную обратную-совместимость кода. Но раз уж решение разрабатывается, смысла, что-то доказывать тоже нет.
#7
-
- Программист ООО "КБ"
-
- 8 761 сообщений
Активный участник
- Пол:Мужчина
- Город:Казань
Отправлено 08 Апрель 2010 - 09:50
kg0 (26.12.2009, 10:45) писал:
Лично мне не хватает:
......
2. Динамического связывания полей в формах ввода (редактирования) записей - т.е. той функции, которая у Вас реализована в режиме создания/редактирования полей, т.е. когда вначале выбираешь тип поля, а последующие поля меняют тип/значение в зависимости от значения предыдущего поля.
......
2. Динамического связывания полей в формах ввода (редактирования) записей - т.е. той функции, которая у Вас реализована в режиме создания/редактирования полей, т.е. когда вначале выбираешь тип поля, а последующие поля меняют тип/значение в зависимости от значения предыдущего поля.
Количество пользователей, читающих эту тему: 3
0 пользователей, 3 гостей, 0 анонимных
