Дабы писать все единообразно
(
    select  $Спр.Код , $Спр.Наименование,$Спр.Единица
вместо текущего
    select  Спр.code,Спр.descr,$Спр.Единица
)

предлагаю добавить в парсер обработку таких выражений.
(те. для справоника выражения типа $Спр.Код заменять на Спр.code)

В принципе у меня есть вариант парсера, реализующего подстановки
"Код","Сode" -> "code"
"Наименование","Description" -> "descr"
"Родитель","Parent" -> "parentid"
"Владелец","Owner" -> "parentext"

Легко можно подобавлять и иные поля (типа ПометкаНаУдаление, ID),
надо только с их именем определиться.

Что народ (и разработчики) скажет по этому поводу?

ну это-то по моему решить можно...

но я все равно считаю также: поначалу действительно непривычно было, но пару месяцев написания кода и - нет проблем - большинство основных идентификаторов таблиц и полей я знаю, так что этот функционал далеко не обязателен, а то так совсем можно забыть "как там все устроено"

Единственный плюс - в зависимости от того: DBF, или SQL - нужно добавлять символ _ к наименованию таблиц, начинающихся с цифры, но так как запросы для разных сред далеко не всегда универсальны, то и эта фишка тут вряд ли сильно поможет

Мое предложение по расширению функционала парсера:
1) добавить все же виртуальные значения разных типов Справочник('B1'), Документ('O1') и т.д. - это используется редко, а потому напрочь забывается
2) ну и сделать таки типизацию видов документов(IDDOCDEF) в строковое выражение, так как они отображаются в конфигураторе - чтобы снять с повестки дня этот постоянно возникающий вопрос!  

"По странному стечению обстоятельств" у справочника вполне могут оказаться (пользовательские) реквизиты Родитель, Владелец, ... 

alexqc писал(а) 25. Августа 2006 :: 08:25:

Их можно сделать и в многоуровневом справочнике с владельцем. А как их 1С распознаёт - это уже другой вопрос. Важно, что в метапарсере это должно разруливаться. Если, конечно, там что-то будет в связи с этим меняться.

Ещё раз. Метапарсер должен однозначно, исходя из текста запроса, выбрать или системное поле или пользовательское. В предложенном варианте эта ситуация не разруливается.

На счёт надуманности проблемы: я тоже считал такие вещи маловероятными и не учитывал их в ранних версиях конструктора запросов. И мне пришлось изменить это мнение на основании реальных багрепортов.

Лично я не за такое расширение метапарсера. В смысле, что я не против такого усовершенствования, но и не за. Имхо, надумано это все.

berezdetsky писал(а) 25. Августа 2006 :: 09:05:


Да почему не разруливается-то? Есть польз. реквизит - используем его. Нет - используем системные. Т.е. ВСЕ работающие до этого запросы - так работающими и останутся. парсер строит текст запроса однозначно, исходя из исходного текста и конфигурации.

Цитата:

"Это не бага, это фича". такого рода места обычно документируются с указанием, что пользователь понимает что делает. А он действительно понимать должен - завтра 1С поменяет порядок поиска реквизитов, и у него все поплывет. Кстати, на счет владельца-родителя не знаю, но точно где-то в ЖКК (может, в метод. рекомендациях) наталкивался на примерно такую фразу - " не рекомендуется задавать измерению регитсра имя "Документ" ". И аналогично - никто не запрещает написать процедуру с системным именем ( Сообщить(), например ). Но если кто так сделает - какова интересно будет реакция на "У меня нифига не сообщает"?

alexqc писал(а) 25. Августа 2006 :: 09:31:


А когда, например, твой напарник, не использующий прямые запросы, добавит подобное поле в справочник, и у тебя "поплывут" все запросы - это тоже будет фича? И где будет твоё "разруливается"?

Это я к тому, что предлагаемый тобой функционал на самом деле не упрощает, а усложняет использование метапарсера. Т.е. - он не нужен. IMHO.

DrACe
+1