В принципе, по технологическим возможностям платформа 1С сильно приблизилась к Аксапте

[belugin]

а использовали ли вы текстовые строки в качестве запросов?

[Reaper]

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

[mazzy]

Цитата:

Сообщение от belugin

а использовали ли вы текстовые строки в качестве запросов?

Максим, этот человек не работал с Аксаптой. Он про 1С рассказывает.

Цитата:

Сообщение от Reaper

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

Цитата:

Сообщение от Reaper

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

Для тех, кто еще не сталкивался с 1С 8.1 и 8.2:
СКД - Система компоновки данных
о ней писалось в этой ветке:
В принципе, по технологическим возможностям платформа 1С сильно приблизилась к Аксапте
В принципе, по технологическим возможностям платформа 1С сильно приблизилась к Аксапте
В принципе, по технологическим возможностям платформа 1С сильно приблизилась к Аксапте
В принципе, по технологическим возможностям платформа 1С сильно приблизилась к Аксапте
В принципе, по технологическим возможностям платформа 1С сильно приблизилась к Аксапте

[belugin]

Теперь вопрос, допустим, вы переименовали поле или перенесли в другую таблицу. Как вы убедитесь, что вы изменили все связанные текстовые запросы - в Ax с Query это делает компилятор.

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

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

[Reaper]

Цитата:

Сообщение от belugin

Теперь вопрос, допустим, вы переименовали поле или перенесли в другую таблицу. Как вы убедитесь, что вы изменили все связанные текстовые запросы - в Ax с Query это делает компилятор.

Модификации запросов обычно делаются в IDE - изменил что-то и изменения пошли во всей структуре загруженной в IDE.

Цитата:

Сообщение от belugin

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

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

Это да, скажу больше - для меня этот язык и есть основной. Весь же остальной язык использую очень мало.

Цитата:

Сообщение от belugin

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

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

[Сисой]

Я использовал несколько раз СКД для управления параметрическими запросами вне задачи получения отчетности. Навскидку напомню об универсальных обработках для работы с разными объектами. Но у СКД есть один минус: хотя источников данных может быть много (в т.ч. и несвязанных между собой), тексты запросов с именами таблиц (предложение From ) все равно хранятся в текстовом виде и их нужно парсить.

[Reaper]

Цитата:

Сообщение от Сисой

Я использовал несколько раз СКД для управления параметрическими запросами вне задачи получения отчетности. Навскидку напомню об универсальных обработках для работы с разными объектами. Но у СКД есть один минус: хотя источников данных может быть много (в т.ч. и несвязанных между собой), тексты запросов с именами таблиц (предложение From ) все равно хранятся в текстовом виде и их нужно парсить.

Источником данных для СКД могут быть и непосредственно объекты. И описать их взаимодействие можно кодом, без вызова IDE вовсе. Вопрос только зачем?

[mazzy]

Цитата:

Сообщение от Reaper

Вопрос только зачем?

Упорно напоминаю нечитателям из-за чего возобновился сыр-бор в этой ветке:

Цитата:

Сообщение от mazzy

Мдя... Некоторые 1Сники задаются вопросом: v8: В чем смысл такого кода

И в самом деле, зачем 1Сники пишут ТАКОЙ код?

[Reaper]

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

[gl00mie]

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


За счет этого пользователи практически на любой форме/отчете/"обработке" могут тонко настроить используемый в дальнейшем запрос без помощи разработчика.

[Reaper]

Теперь мы тоже можем так:


И это все та же Система Компоновки Данных

[mazzy]

Цитата:

Сообщение от Reaper

Теперь мы тоже можем так:

А первый рисунок повторить?
кроме того, в критериях на втором рисунке можно указывать выражения http://axapta.mazzy.ru/lib/search/

[Сисой]

Цитата:

Сообщение от mazzy

А первый рисунок повторить?
кроме того, в критериях на втором рисунке можно указывать выражения http://axapta.mazzy.ru/lib/search/

К сожалению, в базовых отборах гридов 1С даже базовые шаблоны LIKE недоступны. Максимум - возможен поиск подстроки ("Содержит").
В качестве альтернативы 1С предоставляет механизм полнотекстового поиска, существенно превосходящий язык выражений Ax по возможностям:
Полнотекстовый поиск в 1С.

[Reaper]

1. Вида связи 1:n нет как такового.
2. Критерии выбираются только из фиксированного списка

Встречные вопросы:
1. Механизмы AX дают пользователю превратить плоский список в дерево по произвольным полям?

2. На предыдущем рисунке зеленым подсвечено поле "сумма" - это условное оформление, которое позволяет управлять отображением произвольного поля (цвета фона, текста, шрифт, содержание) в зависимости от описанного пользователем критерия. AX имеет аналог?

[mazzy]

Цитата:

Сообщение от Reaper

Встречные вопросы:
1. Механизмы AX дают пользователю превратить плоский список в дерево по произвольным полям?

В дерево - да.

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

По произвольным полям - ни в коем случае нет. Что ж производительностью то будет, если пользователь будет дерево строить по произвольным полям? Да еще по таким, по которым индексов нет... Тут хочется отключить даже сортировку по произвольным полям. А вы дерево предлагаете...

Цитата:

Сообщение от Reaper

2. На предыдущем рисунке зеленым подсвечено поле "сумма" - это условное оформление, которое позволяет управлять отображением произвольного поля (цвета фона, текста, шрифт, содержание) в зависимости от описанного пользователем критерия. AX имеет аналог?

нет, настройки нет.
только программированием.
и только на уровне строки грида.

[gl00mie]

Цитата:

Сообщение от Reaper

На предыдущем рисунке зеленым подсвечено поле "сумма" - это условное оформление, которое позволяет управлять отображением произвольного поля (цвета фона, текста, шрифт, содержание) в зависимости от описанного пользователем критерия. AX имеет аналог?

В AX есть возможность "расцвечивать" строки и/или отдельные поля, но только за счет написания соотв. кода. Аналога "условного форматирования" на основе пользовательских критериев нет, но это, извините, какая-то фильтрация для бедных. Если мне надо будет видеть строки с суммами от сих до сих или больше скольки-то, то я просто задам это условие в фильтре и увижу лишь нужные мне строки, а не буду листать хрендцать экранов, выискивая зеленый фон у полей сумм.

PS. Когда от "светофоров" есть реальная польза, они обычно рисуются по более сложным алгоритмам, чем банальное сравнение, и за счет других инструментов - это скорее область Business Intelligence.

[belugin]

Цитата:

Сообщение от gl00mie

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

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

[gl00mie]

Цитата:

Сообщение от belugin

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

Практическая польза такой наглядности даже в Экселе пропадает, если строк становится больше примерно сотни-другой - и тогда уже приходится прибегать к фильтрации

Цитата:

Сообщение от belugin

В принципе, можно было бы, наверное ограниченно приделать к заданным формам в Ax.

Ну так вам, сотрудникам MS, и карты в руки!

[Сисой]

Цитата:

Сообщение от gl00mie

Когда от "светофоров" есть реальная пользова, они обычно рисуются по более сложным алгоритмам, чем банальное сравнение, и за счет других инструментов - это скорее облать Business Intelligence.

Привожу пример полезного светофора: расцветка строк по статусам заказов, если разработчик не удосужился задать расцветку или обеспечить механизм ее настройки под юзера.

[gl00mie]

Цитата:

Сообщение от Сисой

Привожу пример полезного светофора: расцветка строк по статусам заказов, если разработчик не удосужился задать расцветку или обеспечить механизм ее настройки под юзера.

И что она мне как пользователю дает? Ну вижу я 20 строк, расцвеченных по статусу - дальше что? А если я - оператор, отвечающий за оформление заказов, а заказов у меня - сотня-другая в день, что мне от расцветки 20 заказов на одном экране? Мне тогда интереснее было бы видеть, сколько заказов мне еще надо обработать, по скольки, к примеру, машина вернулась обратно, потому что документы оказались неправильно оформлены, etc, потому что мой заработок как оператора зависит от этого. А в этом случае куда интересней видеть стопочки документов с указанием их количества и "светофор" с расчетом предварительного размера премии, как в том же ролевом центре, а это уже не просто "условное форматирование", а BI.