Практическое метаметамоделирование

[webus]

Очень интересно! А можно ли взглянуть на код? Почему не используете Groovy, в качестве скриптового языка для расширения функционала приложения?

[meta4]

>Почему не используете Groovy
Как раз груви и используется :) Мы написали специально набор оберток, чтобы код выглядил очень естественно. На нем написан код триггеров, действий и конструкторов. Но вообще это временное решение — мы стремимся к декларативности, мы уже придумали соответствующие конструкции, но до реализации их пока дела не дошло.

>А можно ли взглянуть на код?
На код клиента — легко. Я его специально не минифицировал и не обфусцировал. А вот архитектура сервера достаточно нетривиальная, коментариев нет, разобраться будет довольно сложно, да и судьба кода пока не решена.

[webus]

Чем будете заменять Groovy? XML?

[meta4]

Дело не в том что мы заменяем Groovy на XML. Мы заменяем императивный код на декларативное описание, а какой у него будет синтаксис — XML, YAML, графических диаграм или аннтоаций в каком-то ЯП не принципиально.

[webus]

А покажите пример на Groovy?

[meta4]

Класс, реализующий конструктор заявки, который при создании автоматически добавляет в заявку из заданных категорий:

class RequestConstructorLogic extends GroovyEntityConstructorLogic {
    @Override
    IEntityWrapper construct(GroovySupport io, EntityConstructor constructor, IEntityWrapper params, IEntityWrapper owner) {
        def заявка = io.create.Заявка()
        def Номенклатура = io.description.Номенклатура
        def Set<Path> added = new HashSet<Path>();
        for (отдел in params.отделы) {
            for (номенклатура in io.find(Номенклатура, [отделы: отдел])) {
                if (!added.contains(номенклатура.getPath())) {
                    заявка.материалы.add(io.create.Запись([
                            наименование: номенклатура,
                            заказано: 0,
                            отгружено: 0,
                            возвращено: 0
                    ]));
                    added.add(номенклатура.getPath());
                }
            }
            заявка.отдел = отдел
        }
        заявка.заявитель = io.get(io.session.getUser());
        if (params.заказчик != null) {
            заявка.заказчик = params.заказчик
            заявка.адрес = params.заказчик.адрес
        }
        return заявка
    }
}

[webus]

Скрипты храните в БД?

[meta4]

Нет, просто в отдельном модуле, чтобы отлаживать их было удобно.

[dohque]

Такой себе Domain-driven design через XML.

[meta4]

>XML

XML здесь как раз абсолютно не принципиален. Концепцию структурных интерфейсов и вычислимых полей можно протащить и в веб-фреймворки через аннотации.

[dohque]

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

[meta4]

>Так она там уже давно есть

Кто она? Интерфейсов + вычислимых атрибутов я фактически нигде не видел. А это как раз именно то, что мы и предлагаем

>Интерфейсов, может там и нет

Так именно они и являются одним из основных наших тем. А почему они полезны как раз и описывается в статье.

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

[dohque]

Это продали внедрение первому клиенту.