Есть некий класс Db поля которого генерятся макросом в MacroPhase.BeforeTypedMembers.

Есть код его использующий

    class HomeController : Controller
    {
        //tt : Db { get {null} }

        public Index() : ActionResult
        {
            using (db = Db())
            {
                def message = $"NRails env: '$(db.Env)'. We have $(db.Persons.Count()) persons."; 
                def taxonomies =  db.Doctors.Select(d => new (text = d.Taxonomy, doctor = d.PersonID)).ToList();

                View(viewmodel ( message, taxonomies ));
            }
        }
    }

В таком виде все нормально, но если убрать комментарий — интеграция перестает видеть генерируемые поля в классе Db. Компиляция при этом проходит успешно. Можно ли исправить такое поведение?

Здравствуйте, Ziaw, Вы писали:

Z>В таком виде все нормально, но если убрать комментарий — интеграция перестает видеть генерируемые поля в классе Db. Компиляция при этом проходит успешно. Можно ли исправить такое поведение?

Ничего не понятно. Поле не должно мешать видимости генерируемых полей.

Опиши как воспроизвести ошибку, и я погляжу что там происходит.

Могу предположить, что дело в том что твои макросы не рассчитывают на то, что они могу быть вызваны многократно при работе в режиме интеграции.

Кроме того, в режиме интеграции, совершенно неизвестно когда будет обработано тело метода.

Небольшое пояснение.

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

Так как при каждом изменении в очередь помещается запрос на ретипизацию тела метода, это типизация может производиться неопределенное количество раз в течении одной сессии работы с проектом в IDE.

Отсюда следует вывод, что генерация структур данных из тел методов является не лучшим проектным решением.

Я много раз говорил и продолжаю говорить, что лучше всего размещать логику генерирующую код верхнего уровня (типы и их члены) в метаатрибут. Метатрибуты гарантированно исполняются одни раз. При изменении проекта перестраивается вся иерархия типов и метаатрибуты вызываются на новом дереве.

Здравствуйте, VladD2, Вы писали:

VD>Ничего не понятно. Поле не должно мешать видимости генерируемых полей.

VD>Опиши как воспроизвести ошибку, и я погляжу что там происходит.

Пока воспроизводил разобрался Ошибка была совсем в другом месте, при анализе этого свойства глючил другой макрос. Я просто не заметил NRE в куче вываленных ошибок оверлоад резолюшена.

VD>Могу предположить, что дело в том что твои макросы не рассчитывают на то, что они могу быть вызваны многократно при работе в режиме интеграции.

Вроде все затачиваю под многократный вызов, хотя, конечно, гарантировать сложно.

VD>Компиляция тел методов занимает слишком много времени, чтобы производить ее на каждое изменение исходников. Вместо этого тела методов помещаются в очередь и обрабатываются в фоновом режиме. Только что измененные тела методов помещаются в начало очереди, что приводит к тому что они обрабатываются раньше.

VD>Так как при каждом изменении в очередь помещается запрос на ретипизацию тела метода, это типизация может производиться неопределенное количество раз в течении одной сессии работы с проектом в IDE.

Для меня главное, чтобы эта компиляция не происходила до выполнения нужных макросов.

VD>Отсюда следует вывод, что генерация структур данных из тел методов является не лучшим проектным решением.

В теле методов генерится только ViewModel, если придумаешь более удобный вариант генерации ViewModel — предлагай, посмотрим. (в этой проблеме ViewModel совершенно не участвовала, я проверил сразу).

VD>Я много раз говорил и продолжаю говорить, что лучше всего размещать логику генерирующую код верхнего уровня (типы и их члены) в метаатрибут. Метатрибуты гарантированно исполняются одни раз. При изменении проекта перестраивается вся иерархия типов и метаатрибуты вызываются на новом дереве.

Все что можно генерить метаатрибутом генерится метаатрибутом. Я не знал, что он вызывается один раз и на всякий случай писал как для множественных, впрочем очень хорошо, что один, один вероятный сценарий множественного вызова меня напрягал.

Кстати, классы модели и DbManager генерятся макроатрибутами. Как думаешь, может заменить их на обычные атрибуты и заполнять на уровне сборки? А при отсутствии модели в неймспейсе {AssemblyName}.Models генерить еще и сам класс?

Не будет ли проблем с большими схемами в которых приложению требуется только пара таблиц? Впрочем можно такое поведение сделать отключаемым.

Здравствуйте, Ziaw, Вы писали:

Z>Вроде все затачиваю под многократный вызов, хотя, конечно, гарантировать сложно.

А как с добавлением типов и их членов? Это тоже нужно контролировать.

Z>Для меня главное, чтобы эта компиляция не происходила до выполнения нужных макросов.

Это можно гарантировать только если вызвать эти нужные макросы внутри места где это требуется.

Z>В теле методов генерится только ViewModel, если придумаешь более удобный вариант генерации ViewModel — предлагай, посмотрим. (в этой проблеме ViewModel совершенно не участвовала, я проверил сразу).

Если ViewModel используется только из вьюх которые компилируются отдельно, то в общем-то по фигу. Можешь просто проверять что работа идет в режиме интеграции и не выполнять генерацию типов из ViewModel.
Вот только вы там хотели комплит получить и для этого подключали файлы вьюх к проекту. В этом случае ViewModel должен генерировать нужные типы и позаботиться, чтобы они всегда были в единственном экземпляре и в верном состоянии. А это уже не просто (особенно если учесть, что удалять ничего нельзя, только менять).

Z>Все что можно генерить метаатрибутом генерится метаатрибутом. Я не знал, что он вызывается один раз и на всякий случай писал как для множественных, впрочем очень хорошо, что один, один вероятный сценарий множественного вызова меня напрягал.

Ну, хорошо что теперь знаешь. Я не помню описывал ли я это где-то. А информация эта (для продвинутых макросописателей) очень важная. Ее нужно знать и понимать. Иначе будет много траха и мата.

Z>Кстати, классы модели и DbManager генерятся макроатрибутами. Как думаешь, может заменить их на обычные атрибуты и заполнять на уровне сборки? А при отсутствии модели в неймспейсе {AssemblyName}.Models генерить еще и сам класс?

Это ты сам должен решать. Это вопрос дизайна. Я не настолько знаком с твоими решениями чтобы что-то тут советовать. В принципе, генерация классов на метатрибутах — это хорошее решение. При этом, кстати, можно и обычные атрибуты теми же макроатрибутами прицепить (если в рантайме что-то нужно будет знать).

Z>Не будет ли проблем с большими схемами в которых приложению требуется только пара таблиц? Впрочем можно такое поведение сделать отключаемым.

Я не очень понимаю контекста. Если у тебя все в одном проекте, то не ясно зачем делать большую схему БД, если из нее используется две таблицы. Если же речь о двух разных проектах в первом из которых работают макроатрибуты, а второй из которых использует нагенерированные ими классы, то проблем быть не должно, так как второй проект увидит сгенерированные классы только после перекомпиляции первого (интеграция на сегодня проекты связывает только через сборки).

Здравствуйте, VladD2, Вы писали:

VD>А как с добавлением типов и их членов? Это тоже нужно контролировать.

Контролируется.

VD>Если ViewModel используется только из вьюх которые компилируются отдельно, то в общем-то по фигу. Можешь просто проверять что работа идет в режиме интеграции и не выполнять генерацию типов из ViewModel.
VD>Вот только вы там хотели комплит получить и для этого подключали файлы вьюх к проекту. В этом случае ViewModel должен генерировать нужные типы и позаботиться, чтобы они всегда были в единственном экземпляре и в верном состоянии. А это уже не просто (особенно если учесть, что удалять ничего нельзя, только менять).

С комплитом вообще все грустно Спарковская интеграция написана частично на C++, а я с ним не очень дружу, особенно с COM. Вроде заюзал ContainedLanguage от немерла, дал ему нужный код, но так и не взлетело, а куда копать совершенно не представляю.

VD>Я не очень понимаю контекста. Если у тебя все в одном проекте, то не ясно зачем делать большую схему БД, если из нее используется две таблицы. Если же речь о двух разных проектах в первом из которых работают макроатрибуты, а второй из которых использует нагенерированные ими классы, то проблем быть не должно, так как второй проект увидит сгенерированные классы только после перекомпиляции первого (интеграция на сегодня проекты связывает только через сборки).

Контекст — простенькая вебморда к имеющейся большой базе. Вобщем сделаю флажок конфигурации, генерить ли недостающие модели.

[offtopic]IT вроде делает чтение схемы в тулките, так что в рельсах останется только генератор DDL, что не может не радовать.[/offtopic]

Здравствуйте, Ziaw, Вы писали:

Z>С комплитом вообще все грустно Спарковская интеграция написана частично на C++, а я с ним не очень дружу, особенно с COM. Вроде заюзал ContainedLanguage от немерла, дал ему нужный код, но так и не взлетело, а куда копать совершенно не представляю.

Вот это и есть те проблемы которые я подразумевал когда говорил о юзании внешних компонентов.

Тем временем я потратил субботу на то, чтобы налабать каркас для макры "xml литерал". Она в черне парсит ХМЛ. В итоге она должна преобразовывать его в XmlAst. По XmlAst уже можно будет строить прикладной код со сплайсами, блэкджеком и шлюхами .

Я хочу реализовать универсальное решение для работы с XML-ем.

Но на базе этого парсера можно будет сделать и более специализированное решение для работы с HTML на базе типизированного HTML-AST.

Ты, кстати, просил привести пример того как может выглядеть такое AST. Недавно такой пример нашелся — Open XML SDK 2.0. Погляди его описание и примеры. Это то о чем я говорил, только применительно не к HTML, а к XML-форматам MS Office. Вот заметка в блоге нашего Голумна. Там на об Open XML SDK рассказано в кратце и на пальцах.

Так вот, можно создать аналогичную объектную модель для HTML-я (с поддержкой расширений, встроенных управляющих конструкций и трансформаций) и обернуть это дело макросами которые я делаю для работы с XML-ем.

В результате должно получиться весьма красивое и мощное решение которое спокойно заменит Спарк. Ну, а пока можно и Спарком пользоваться. (вот только времени бы найти...)

Z>Контекст — простенькая вебморда к имеющейся большой базе.

Дык а зачем же все таблицы то генерировать? Можно же генерить только те что нужны в конкретном проекте.

Z>Вобщем сделаю флажок конфигурации, генерить ли недостающие модели.

Не понял что кроется за термином "недостающие", но наверно это то что я имел в виду.

Z>[offtopic]IT вроде делает чтение схемы в тулките, так что в рельсах останется только генератор DDL, что не может не радовать.[/offtopic]

+1
Качественная халява не может не радовать!

Здравствуйте, VladD2, Вы писали:

Z>>С комплитом вообще все грустно Спарковская интеграция написана частично на C++, а я с ним не очень дружу, особенно с COM. Вроде заюзал ContainedLanguage от немерла, дал ему нужный код, но так и не взлетело, а куда копать совершенно не представляю.

VD>Вот это и есть те проблемы которые я подразумевал когда говорил о юзании внешних компонентов.

Какие? То, что готовая интеграция не работает и нужно писать свою? Так если бы я писал спарк сам, мне бы пришлось писать и спарк и интеграцию А так только интеграцию. Грустно, потому, что не хотелось лезть в апи 2008 студии, в 2010 все как-то ближе к людям сделано.

VD>Я хочу реализовать универсальное решение для работы с XML-ем.

Ага, я видел. Думаю его можно будет использовать в инплейс вьюхах. И в будущем с поддержкой IDE превратить в свой viewengine.

VD>Так вот, можно создать аналогичную объектную модель для HTML-я (с поддержкой расширений, встроенных управляющих конструкций и трансформаций) и обернуть это дело макросами которые я делаю для работы с XML-ем.

Мы сейчас опять скатимся в срач То, что прекрасно подходит для построения OpenXml, для генерации html выглядит не очень. Ну не представляю я, чтобы мне понадобилось генерить html именно в коде, оно получается плохо поддерживаемо.

VD>В результате должно получиться весьма красивое и мощное решение которое спокойно заменит Спарк. Ну, а пока можно и Спарком пользоваться. (вот только времени бы найти...)

+1

VD>Дык а зачем же все таблицы то генерировать? Можно же генерить только те что нужны в конкретном проекте.

Да я вот задумался, зачем вообще создавать пустые классы и помечать их макрой модель? Пусть вся база присутствует в проекте сразу, если это не выключено в конфиге. Если нужно кастомайзить класс — пожалуйста пишем его, объявляем нужные поля, остальное догенерит движок.

Здравствуйте, Ziaw, Вы писали:

Z>Да я вот задумался, зачем вообще создавать пустые классы и помечать их макрой модель? Пусть вся база присутствует в проекте сразу, если это не выключено в конфиге. Если нужно кастомайзить класс — пожалуйста пишем его, объявляем нужные поля, остальное догенерит движок.

Не скатимся, так как впредь на необоснованные заявления я просто не буду реагировать.

Скажу только что использовать типизированный AST HTML-я напрямую при наличии движка его поддерживающего и не нужно (разве что изредка, когда движок по гибкости не дотягивает). А вот его использование в самом движке позволила бы сделать гибкую обработку в купе с проверками корректности HTML-я во время компиляции. Причем все проверки делал бы компилятор сам, так как они целиком легли бы на систему типов.

С XML-движком основанном на xlinq компайлтайм-проверок особо не добиться, так как xlinq слишком часто оперирует с типом object. А вот со строгой объектной моделью вроде OpenXml или HtmlAst — это можно сделать запросто.

Здравствуйте, Ziaw, Вы писали:

Z>Да я вот задумался, зачем вообще создавать пустые классы и помечать их макрой модель? Пусть вся база присутствует в проекте сразу, если это не выключено в конфиге. Если нужно кастомайзить класс — пожалуйста пишем его, объявляем нужные поля, остальное догенерит движок.

Дык создай глобальный метаатрибут. Перчисли в нем необходимые таблицы. Пусть только для них обвязка и генерируется. Можно даже использовать * и ? для указания шаблонов, если влом перечислять все таблицы.