Мы все знаем упражнение: у вас есть (небольшая) модель, вам нужно ее сохранить, вам нужен пользовательский интерфейс (веб, рабочий стол, мобильный, некоторые из первых, все).
Это такой повторяющийся процесс, что я не могу не задаться вопросом, почему мы все еще зацикливаемся на POJO, OR mappers и кодировании пользовательских интерфейсов от руки (поскольку большинство дизайнеров UI даже не знают о наследовании, и вам нужно для создания каждого диалога ОК/Отмена с более чем одним полем с нуля). RAD инструменты/платформы обещают исправить это, но я пока ничего не видел. Идея этой вики состоит в том, чтобы собрать все инструменты, которые позволят вам воплотить идею за несколько минут и построить оттуда. Простые вещи (например, создание простого пользовательского интерфейса для вашей модели или сохранение его в базе данных) должны быть простыми. Прикрепление довольно сложного объекта к диалогу для его редактирования должно занимать одну строку кода или меньше;)
Итак, вот вызов: какие инструменты RAD существуют, которые позволяют построить небольшое приложение, например, через 8 часов. Чтобы дать вам представление о том, что он должен делать, вот спецификация:
-
У вас есть узлы "знаний". Каждый такой node имеет имя и длинное описание, прикрепленное к нему (однострочная и многострочная строка)
-
Каждое знание node может иметь любое количество узлов знаний в качестве дочерних элементов (соотношение 1: * с родительским/дочерним отношением). Ребенок-узлы должны поддерживать порядок (т.е. Использовать список, а не набор)
-
Каждое знание node может иметь любое количество прикрепленных к нему тегов (1: * неупорядоченное отношение между различными типами)
-
Любые два узла знаний могут быть связаны с любым числом отношений (отношение n: m)
-
Должна быть возможность загрузки/сохранения модели из/в формате XML и из/в базе данных с минимальными усилиями
-
Пользователи ожидают отменить/повторить сегодня
Пользовательский интерфейс должен предлагать стандартные операции: создавать, изменять порядок и удалять узлы знаний. Переупорядочение должно использовать drag'n'drop. Он должен позволять добавлять/удалять теги из узлов знаний. Должен быть простой способ связать два узла знаний по отношению (например, перетащив один node на другой в специальном режиме).
Пользовательский интерфейс также должен позволять искать узлы с сертификатами или отношениями. Для бонусных очков он должен предложить простой способ навигации по графику отношений.
В чем проблема? Как обычно, предпочитается OSS.
Справочная информация. Я разрабатываю программное обеспечение уже более 25 лет. Тем не менее, это простое приложение занимает несколько недель, если не месяцев, чтобы закодировать на любом языке, с которым я столкнулся до сих пор: Groovy, Java, Python, Tcl/Tk, Grails, OpenOffice, MS Access, TreeLine, [TurboGears] [10], [Enthought Traits] [11],.net.
Некоторые отзывы о претендентах. Обратите внимание, что я пытаюсь выделить основной пункт в одном предложении, поэтому возьмите следующий раздел с солью, ОК?
Groovy Хороший язык, компактный код. Закрыть, но не хватает в отделе пользовательского интерфейса. Они работают над этим, но просто нет. Для настойчивости, только сериализация Java из коробки.
Java Java была великолепна, когда она появилась десять лет назад, но она так не развивалась. Это стареющий язык с огромным набором библиотек, но вам просто нужно слишком много кода, чтобы все было сделано, и каждая строка кода требует времени для записи.
Python Получил почти все, что ему нужно, но по какой-то причине он никогда не становился как основной, как, скажем, Java. Получил хороший набор пользовательских интерфейсов с PyQt4, классный конвертер OR с SQLAlchemy, но, тем не менее, мы не видим, чтобы он полностью ударил дроссель до полной скорости. Только с появлением модульных испытаний стало возможным писать большие проекты. Слишком низкий уровень для задачи.
Tcl/Tk Хороший виджет установлен, но язык засасывает, когда размер кода превышает некоторую точку. Показывает свой возраст.
OpenOffice. Начиная с версии 2.0, OO поставляется со встроенной базой данных и средством "Access-like". Это в зачаточном состоянии, но они доберутся... в конце концов. Не удалось обработать отношения между родителями и дочерними элементами, потому что пользовательский интерфейс не позволяет их указывать (видеть ошибку). Исправлено в 3.1. С помощью 3.1 вы можете создать модель, но пользовательский интерфейс все равно займет много времени.
MS Access Почти все, что нам нужно, но параметры пользовательского интерфейса довольно ограничены. Разочарование.
TreeLine. Невозможно реализовать отношения и слишком ограничено для большинства других случаев использования (вы просто не можете делать с ним ничего другого)
.net У меня нет опыта работы с этим, главным образом потому, что это только Windows. Я думаю, что этот человек может быть довольно близок, но пусть сталкивается с этим: какой смысл блокировать четверть человечества?
