есть предложение написать свой генератор отчетов (типа RSDNReports ). Я бы например мог присоедениться к такому проекту (тоже не могу найти душевного генератора)
Замичатишно. Давай, присоединяйся. Как раз нужно сделать генератор. Существующий работает с Word'ом и, конечно, слабоват. Для начала постите сюда с SharpStudent'ом свои идеи.
Здравствуйте, Poudy, Вы писали:
P> Для начала постите сюда с SharpStudent'ом свои идеи.
Мне например не хватает динамического генерирования отчетов (сильно не хватает)
есть предложение написать свой генератор отчетов (типа RSDNReports ). Я бы например мог присоедениться к такому проекту (тоже не могу найти душевного генератора)
P>Замичатишно. Давай, присоединяйся. Как раз нужно сделать генератор. Существующий работает с Word'ом и, конечно, слабоват. Для начала постите сюда с SharpStudent'ом свои идеи.
А есть ли какие собственные идеи по поводу движка? В данном случае это вопрос первостепенной важности. Было бы интересно рассмотреть и другие варианты.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>А есть ли какие собственные идеи по поводу движка? В данном случае это вопрос первостепенной важности. Было бы интересно рассмотреть и другие варианты.
Чуть меньше года назад я некоторое время экспериментировал над прототипом движка — как на мой взгляд, удобнее использовать xml-шаблон, который и отображать. Тогда можно спокойно разделить реализации дизайнера и просмотрщика. И, чтобы было проще реализовывать новые возможности, надо сделать расширяемый формат шаблона и нечто вроде поддержки плагинов (комплементарные, для дизайнера и для просмотрщика) — причем если отсутствует поддержка какой-либо части шаблона, то она просто не отображается. Для шаблона неплохо было бы предусмотреть шифрование. Интересно было бы видеть возможность сохранения готового отчета в потоке в шифрованном виде с подписью и без возможности его редактирования.
Здравствуйте, Ved, Вы писали:
Ved>Здравствуйте, Воронков Василий, Вы писали:
ВВ>>А есть ли какие собственные идеи по поводу движка? В данном случае это вопрос первостепенной важности. Было бы интересно рассмотреть и другие варианты.
Ved>Чуть меньше года назад я некоторое время экспериментировал над прототипом движка — как на мой взгляд, удобнее использовать xml-шаблон, который и отображать.
Здравствуйте, Ved, Вы писали:
Ved>Чуть меньше года назад я некоторое время экспериментировал над прототипом движка — как на мой взгляд, удобнее использовать xml-шаблон, который и отображать. Тогда можно спокойно разделить реализации дизайнера и просмотрщика. И, чтобы было проще реализовывать новые возможности, надо сделать расширяемый формат шаблона и нечто вроде поддержки плагинов (комплементарные, для дизайнера и для просмотрщика) — причем если отсутствует поддержка какой-либо части шаблона, то она просто не отображается.
В принципе все правильно. В дополнение я бы предложил для самих шаблонов использовать формат xslt, в качестве результирующего файла xsl:fo. Тогда процесс генерации отчета в простейшем случае выглядел бы так.
SELECT ... FOR XML. Получаем из БД исходные данные.
Далее этот xml внутренними средствами генератора отчетов преобразуется в xsl:fo, который затем можно сразу показать, а можно конвертануть стандартными средствами в pdf, doc, html, rtf и прочая.
Здравствуйте, Воронков Василий, Вы писали:
Ved>>Чуть меньше года назад я некоторое время экспериментировал над прототипом движка — как на мой взгляд, удобнее использовать xml-шаблон, который и отображать.
ВВ>Как отображать?
"Рендерить" в смысле. Опираясь на данные (обычно внешние, хотя можно сделать допустимым и встраивание их в шаблон, но тогда его желательно защищать и запрещать менять данные (часть, отвечающую за внешний вид, менять можно разрешить редактировать))
Здравствуйте, AndrewVK, Вы писали:
AVK>Далее этот xml внутренними средствами генератора отчетов преобразуется в xsl:fo, который затем можно сразу показать, а можно конвертануть стандартными средствами в pdf, doc, html, rtf и прочая.
Вполне согласен, но не совсем представляю, как показать xsl:fo в скажем .NET-овском ReportViewer'е...
Заодно таким образом можно будет проще реализовать экспорт в другие форматы — причем можно реализовать различную поддержку для форматов в зависимости от версии (trial, Professional, Enterprize или чего-нибудь еще ).
Здравствуйте, Ved, Вы писали:
Ved>Вполне согласен, но не совсем представляю, как показать xsl:fo в скажем .NET-овском ReportViewer'е...
Вариантов несколько
1) Написать самим рендерер
2) Прикрутить апачевский FOP, но он написан на джаве
3) Портануть его на дотнет (можно поглядеть в каком состоянии sourceforge.net/projects/nfop)
4) Предложить пользователю купить какой нибудь коммерческий FO-рендерер, например XEP.
Ved>Заодно таким образом можно будет проще реализовать экспорт в другие форматы — причем можно реализовать различную поддержку для форматов в зависимости от версии (trial, Professional, Enterprize или чего-нибудь еще
Еще один плюс — легкость написания плагинов к репортеру, обеспечивающих отображение тех или иных конструкций. По сути такой плагин может представлять собой просто преобразователь некоего xml в xsl:fo. Большинство примитивов вобще не потребуют кода, это будет просто xslt-шаблон с привязанными к нему метаданными.
Здравствуйте, AndrewVK, Вы писали:
Ved>>Вполне согласен, но не совсем представляю, как показать xsl:fo в скажем .NET-овском ReportViewer'е...
AVK>Вариантов несколько AVK>1) Написать самим рендерер
С одной стороны, самый геморный вариант, зато, с другой, — достаточно заманчивый — ни от кого не зависеть в первую очередь, баги — свои , фиксить попроще (не надо в чужом коде разбираться). Проблема — человеко-месяцы. Вопрос — сколько ориентировочно на это может уйти? (Спрашиваю потому, что с xsl:fo не работал, но интересно) Если до человеко-года-полутора при возможности писать втроем-четвером — то это терпимо.
AVK>2) Прикрутить апачевский FOP, но он написан на джаве
Сомнительная выгода. AVK>3) Портануть его на дотнет (можно поглядеть в каком состоянии sourceforge.net/projects/nfop)
А как у них с лицензированием? С багами (фиксить кому? самим в чужом коде разбираться — неблагодарнейшее дело, особенно если писалось кое-как)?
AVK>4) Предложить пользователю купить какой нибудь коммерческий FO-рендерер, например XEP.
Ну-ну... Иначе как шутку это воспринять тяжело — пользователь вообще такой зверь, что неохотно с $$ расстается...
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Ved, Вы писали:
Ved>>Вполне согласен, но не совсем представляю, как показать xsl:fo в скажем .NET-овском ReportViewer'е...
AVK>Вариантов несколько AVK>1) Написать самим рендерер AVK>2) Прикрутить апачевский FOP, но он написан на джаве AVK>3) Портануть его на дотнет (можно поглядеть в каком состоянии sourceforge.net/projects/nfop) AVK>4) Предложить пользователю купить какой нибудь коммерческий FO-рендерер, например XEP.
Хм, имхо тяжеловатое решение. Может, стоит вообще подойти с другого конца? Например, документ отчета, представленный в виде графа объектов, можно прорисовывать вручную через GDI+ или руками конвертить в ХТМЛ и использовать для просмотра браузер (хотя этот вариант мне не особо по душе).
Здравствуйте, Ved, Вы писали:
Ved> Вопрос — сколько ориентировочно на это может уйти?
Если необходимый минимум (примитивы, текст, таблицы и управление форматированием простейшее) то недолго. Если весь стандарт то очень много.
AVK>>2) Прикрутить апачевский FOP, но он написан на джаве Ved>Сомнительная выгода.
Ну как сказать — зато бесплатный и регулярно обновляемый.
AVK>>3) Портануть его на дотнет (можно поглядеть в каком состоянии sourceforge.net/projects/nfop) Ved>А как у них с лицензированием?
Обычная апачевская лицензия.
Ved>С багами (фиксить кому? самим в чужом коде разбираться — неблагодарнейшее дело, особенно если писалось кое-как)?
Ну вобще то апачевские проекты написаны относительно качественно.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Хм, имхо тяжеловатое решение.
Зато стандартное.
ВВ>Может, стоит вообще подойти с другого конца? Например, документ отчета, представленный в виде графа объектов, ВВ> можно прорисовывать вручную через GDI+ или руками конвертить в ХТМЛ и использовать для просмотра браузер (хотя этот вариант мне не особо по душе).
И чем это отличается от предложенного, окромя изобретения собственных форматов ака велосипедов?
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Ved, Вы писали:
Ved>> Вопрос — сколько ориентировочно на это может уйти?
AVK>Если необходимый минимум (примитивы, текст, таблицы и управление форматированием простейшее) то недолго. Если весь стандарт то очень много.
Сорри, а можно ссылку на стандарт, если под рукой? Если нет, то и ладно — думаю на w3c искать не слишком долго придется.
AVK>>>2) Прикрутить апачевский FOP, но он написан на джаве Ved>>Сомнительная выгода. AVK>Ну как сказать — зато бесплатный и регулярно обновляемый.
Да, это конечно большой плюс, вот только насколько быстрым получится взаимодействие .NET с Java? Пользователи всегда хотят побыстрее. Причем ориентироваться надо на машинки порядка Cel 500 128 RAM... Сейчас таких в офисах полным полно. А многие отчеты, которые им хотелось бы видеть, не одну страницу занимают — бывают и до сотни и более, хотя ориентироваться надо в среднем на 10.
AVK>>>3) Портануть его на дотнет (можно поглядеть в каком состоянии sourceforge.net/projects/nfop) Ved>>А как у них с лицензированием? AVK>Обычная апачевская лицензия.
Честно говоря, не обращал внимания... Там коммерческое использование разрешается?
Здравствуйте, AndrewVK, Вы писали:
ВВ>>Хм, имхо тяжеловатое решение. AVK>Зато стандартное.
Ну мне кажется, что если мы в итоге остановимся на нестандартном решении, то ничего особо критичного в этом не будет.
ВВ>>Может, стоит вообще подойти с другого конца? Например, документ отчета, представленный в виде графа объектов, ВВ>> можно прорисовывать вручную через GDI+ или руками конвертить в ХТМЛ и использовать для просмотра браузер (хотя этот вариант мне не особо по душе). AVK>И чем это отличается от предложенного, окромя изобретения собственных форматов ака велосипедов?
ОК. Попробуем разобраться. Предложенная тобой схема выглядит так: XML -> XML -> XSL:FO
Может, я что и не допонял, но получается, что работа репортера завязана на конкретном формате. Собственно, основное различие как раз в том, что я предлагаю вместо этого использовать граф объектов, что позволит максимально абстрагириваться от любого формата в принципе. Т.е схема уже будет выглядеть так: XML|DataSet -> reportDocument -> ...
А если использовать для представления HTML (генерить его по reportDocument), то и задача рендеринга значительно упростится.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Ну мне кажется, что если мы в итоге остановимся на нестандартном решении, то ничего особо критичного в этом не будет.
ИМХО как раз весьма критично. В случае стандартного решения у пользователя всегда есть возможность заменить куски нашей системы, поскольку формат данных между ними стандартизован.
AVK>>И чем это отличается от предложенного, окромя изобретения собственных форматов ака велосипедов?
ВВ>ОК. Попробуем разобраться. Предложенная тобой схема выглядит так: XML -> XML -> XSL:FO
ВВ>Может, я что и не допонял, но получается, что работа репортера завязана на конкретном формате.
Который формат ты имеешь ввиду?
ВВ>Собственно, основное различие как раз в том, что я предлагаю вместо этого использовать граф объектов, что позволит максимально абстрагириваться от любого формата в принципе.
Граф объектов это тоже формат, только формат не данных, а формат интерфейсов.
ВВ>А если использовать для представления HTML (генерить его по reportDocument), то и задача рендеринга значительно упростится.
Здравствуйте, Ved, Вы писали:
Ved>Сорри, а можно ссылку на стандарт, если под рукой? Если нет, то и ладно — думаю на w3c искать не слишком долго придется.
http://www.w3.org/TR/xsl/
AVK>>Ну как сказать — зато бесплатный и регулярно обновляемый. Ved>Да, это конечно большой плюс, вот только насколько быстрым получится взаимодействие .NET с Java?
А зачем оно, взаимодействие? Его фактически не будет. Репортер подготовит xsl:fo файл и отдаст его фопу, тот сделает из него результат.
AVK>>Обычная апачевская лицензия. Ved>Честно говоря, не обращал внимания... Там коммерческое использование разрешается?
Без ограничений. Единственное требование — наличие в документации на продукт апачевских копирайтов и лизензии.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, AndrewVK, Вы писали:
ВВ>>>Хм, имхо тяжеловатое решение. AVK>>Зато стандартное.
ВВ>>> можно прорисовывать вручную через GDI+ или руками конвертить в ХТМЛ и использовать для просмотра браузер (хотя этот вариант мне не особо по душе).
Лучше с HTML-представлением не связываться — ты представляешь, как его качественно распечатать? Я — нет. Через WebBrowser control качественно не получится. Под качеством я понимаю одинаковую работу независиио от принтера и пр. внешних условий.
ВВ>ОК. Попробуем разобраться. Предложенная тобой схема выглядит так: XML -> XML -> XSL:FO ВВ>Может, я что и не допонял, но получается, что работа репортера завязана на конкретном формате.
В смысле? завязка вообще-то на xsl:fo, а это стандарт, что дает некоторые преимущества. В при изменении и разных версиях шаблонов отчета надо будет просто добавить новое xslt-преобразование.
ВВ>Собственно, основное различие как раз в том, что я предлагаю вместо этого использовать граф объектов, что позволит максимально абстрагириваться от любого формата в принципе. Т.е схема уже будет выглядеть так: XML|DataSet -> reportDocument -> ...
Ок. А как насчет экспорта в другие форматы? doc? rtf? pdf? xls? Причем офиса и пр. может на машине и не быть... А так можно было бы использовать уже существующие.
ВВ>А если использовать для представления HTML (генерить его по reportDocument), то и задача рендеринга значительно упростится.
Нисколько, т.к. как я написал выше, WebBrowser control не особо подходит для печати вообще.
А вообще — везде свои плюсы и минусы. Это надо смотреть по трудозатратам. Кроме того, граф объектов отрисовать на не так просто в отчете будет. Это надо хорошо движок проектировать. Граф будет в любом случае, вопрос — какой... Уже пробовал графы отрисовывать для отчета. При отрисовке нельзя забывать, какая страница, какие поля, какая разбивка, где нужны какие пункты... Движок должен быть очень грамотно реализован и событий с их обработчиками там будет предостаточно.
Здравствуйте, AndrewVK, Вы писали:
AVK>http://www.w3.org/TR/xsl/
Сенкс. Почитаю на досуге.
AVK>>>Ну как сказать — зато бесплатный и регулярно обновляемый. Ved>>Да, это конечно большой плюс, вот только насколько быстрым получится взаимодействие .NET с Java? AVK>А зачем оно, взаимодействие? Его фактически не будет. Репортер подготовит xsl:fo файл и отдаст его фопу, тот сделает из него результат.
Может, я не совсем понимаю, но цепь событий получается такая:
1) Юзер хочет просмотреть отчет перед печатью.
а) запрашивается шаблон
б) заполняем шаблон данными
в) преобразования до xsl:fo
г) Юзер ждет окна с внешним видом отчета. Кто его покажет? .NET или Java-вский конвертер?
2) Юзер отправляет на печать
а) ....
б) ....
в) ....
г) Кто печатает отчет вместе со всеми настройками?
AVK>>>Обычная апачевская лицензия. AVK>Без ограничений. Единственное требование — наличие в документации на продукт апачевских копирайтов и лизензии.
Это весьма good
Здравствуйте, AndrewVK, Вы писали:
ВВ>>Ну мне кажется, что если мы в итоге остановимся на нестандартном решении, то ничего особо критичного в этом не будет. AVK>ИМХО как раз весьма критично. В случае стандартного решения у пользователя всегда есть возможность заменить куски нашей системы, поскольку формат данных между ними стандартизован.
Так вот насколько критично наличие такой возможности у пользователя? Я согласен, что стандарт — это есть гуд, но если получится более удачное решение без его соблюдения, то вполне можно поступиться.
AVK>>>И чем это отличается от предложенного, окромя изобретения собственных форматов ака велосипедов? ВВ>>ОК. Попробуем разобраться. Предложенная тобой схема выглядит так: XML -> XML -> XSL:FO ВВ>>Может, я что и не допонял, но получается, что работа репортера завязана на конкретном формате. AVK>Который формат ты имеешь ввиду?
Формат данных, пользуясь твоим выражением. Т.е. любой формат данных вообще.
ВВ>>Собственно, основное различие как раз в том, что я предлагаю вместо этого использовать граф объектов, что позволит максимально абстрагириваться от любого формата в принципе.
AVK>Граф объектов это тоже формат, только формат не данных, а формат интерфейсов.
Ну можно и так сказать. Вот как раз данная модель мне и кажется более удачной. Основная логика будет вообще никак не связана с тем, что ты называешь форматами данных. То есть вместо того, чтобы работать с хмл и его объектной моделью, мы будем работать с объектной моделью собственно графа. Что позволяет четко отделить 1) представления, 2)собственно сам "отчет", 3)"формат" отчета(доп., результат сериализации).
А это как раз хорошо. Позволит сделать систему более масштабируемой. XML — это далеко не единственный вариант, к-й можно использовать. Можно сохранять через бин. форматтер, отрисовывать самому, и XML вообще как бы окажется не причем. ПРи использовании графа такой переход не приведт ни к каким изменениям в самом типе ReportDocument. Если не использовать граф, то всю логику в принципе придется переписывать.
ВВ>>А если использовать для представления HTML (генерить его по reportDocument), то и задача рендеринга значительно упростится. AVK>Ничуть
Ну мне кажется, что ХТМЛ все же упрощает некоторые задачи — например, легко разделить данные и представления посредством CSS. Возможность, устанавливать Layoutы, комбинировать разные на одной странице. Плюс средства скиптования, с помощью к-х в отчет можно добавить кое-какие вкусные фичи. Ну и пр.
Здравствуйте, Ved, Вы писали:
ВВ>>>> можно прорисовывать вручную через GDI+ или руками конвертить в ХТМЛ и использовать для просмотра браузер (хотя этот вариант мне не особо по душе). Ved>Лучше с HTML-представлением не связываться — ты представляешь, как его качественно распечатать? Я — нет. Через WebBrowser control качественно не получится. Под качеством я понимаю одинаковую работу независиио от принтера и пр. внешних условий.
Конечно, ХТМЛ не создан для печати, но если правильно построить документ — не используя position:absolute и пр., то проблем быть не должно . Со своими аки отчетами на ХТМЛе у меня проблем не было по кр. мере. Хотя печатал на куче принтеров, через ахБраузер. Могу даже попытаться вспомнить что за принтеры. Просто уж очень много вкусностей дает ХТМЛ.
ВВ>>ОК. Попробуем разобраться. Предложенная тобой схема выглядит так: XML -> XML -> XSL:FO ВВ>>Может, я что и не допонял, но получается, что работа репортера завязана на конкретном формате. Ved>В смысле? завязка вообще-то на xsl:fo, а это стандарт, что дает некоторые преимущества. В при изменении и разных версиях шаблонов отчета надо будет просто добавить новое xslt-преобразование. ВВ>>Собственно, основное различие как раз в том, что я предлагаю вместо этого использовать граф объектов, что позволит максимально абстрагириваться от любого формата в принципе. Т.е схема уже будет выглядеть так: XML|DataSet -> reportDocument -> ... Ved>Ок. А как насчет экспорта в другие форматы? doc? rtf? pdf? xls? Причем офиса и пр. может на машине и не быть... А так можно было бы использовать уже существующие.
Я не против стандарта, я против, извиняюсь за каламбур, включения стандарта в стандарт. Можно работать с графом, и уже _на_основе_его_ генерить xsl:fo
Ved>А вообще — везде свои плюсы и минусы. Это надо смотреть по трудозатратам. Кроме того, граф объектов отрисовать на не так просто в отчете будет. Это надо хорошо движок проектировать. Граф будет в любом случае, вопрос — какой... Уже пробовал графы отрисовывать для отчета. При отрисовке нельзя забывать, какая страница, какие поля, какая разбивка, где нужны какие пункты... Движок должен быть очень грамотно реализован и событий с их обработчиками там будет предостаточно.
100% согласен. Я когда начинал копаться с тем же принтДокумент, у меня поначалу вызывало затруднение даже распечатке текста без разделения на строки. Но ведь никто и не говорил, что будет легко
Здравствуйте, Воронков Василий, Вы писали:
AVK>>ИМХО как раз весьма критично. В случае стандартного решения у пользователя всегда есть возможность заменить куски нашей системы, поскольку формат данных между ними стандартизован.
ВВ>Так вот насколько критично наличие такой возможности у пользователя?
Если не забывать о том что пользователь это программист то довольно критично.
AVK>>Который формат ты имеешь ввиду?
ВВ>Формат данных, пользуясь твоим выражением.
На формат данных не завязан. На формат входных данных завязан только конкретный шаблон.
AVK>>Граф объектов это тоже формат, только формат не данных, а формат интерфейсов.
ВВ>Ну можно и так сказать. Вот как раз данная модель мне и кажется более удачной.
Чем?
ВВ>Основная логика будет вообще никак не связана с тем, что ты называешь форматами данных.
Ничего не понимаю. Каким образом твои данные попадут в граф шаблона?
ВВ>То есть вместо того, чтобы работать с хмл и его объектной моделью, мы будем работать с объектной моделью собственно графа.
Ну и чем это лучше кроме изобретения велосипеда?
ВВ>Что позволяет четко отделить 1) представления, 2)собственно сам "отчет", 3)"формат" отчета(доп., результат сериализации).
Он и так четко отделен.
ВВ>А это как раз хорошо. Позволит сделать систему более масштабируемой. XML — это далеко не единственный вариант, к-й можно использовать.
Если ты о входных данных, то средствами дотнета XML можно легко получить из DataSet. По сути тот же граф.
ВВ> Можно сохранять через бин. форматтер, отрисовывать самому,
Что то я никак тебя не пойму. То ты про входные данные, то ты про шаблоны, теперь уже про данные для отрисовки. Какая то у тебя каша получается. Итак есть вполне отдельные сущности:
1) Входные данные
2) Шаблон отчета
3) Готовый отчет
О формате чего ты речь ведешь? Какой формат должна иметь каждая из этих сущностей?
ВВ>Если не использовать граф, то всю логику в принципе придется переписывать.
Да ну?
AVK>>Ничуть
ВВ>Ну мне кажется, что ХТМЛ все же упрощает некоторые задачи — например, легко разделить данные и представления посредством CSS.
И что? Зачем ее разделять в уже готовом отчете?
ВВ>Возможность, устанавливать Layoutы, комбинировать разные на одной странице.
Здравствуйте, Ved, Вы писали:
Ved>1) Юзер хочет просмотреть отчет перед печатью. Ved> а) запрашивается шаблон
Да
Ved> б) заполняем шаблон данными
Да
Ved> в) преобразования до xsl:fo
Да
Ved> г) Юзер ждет окна с внешним видом отчета. Кто его покажет? .NET или Java-вский конвертер?
Ни тот и не другой, а например Acrobat Reader .
Ved>2) Юзер отправляет на печать Ved> а) .... Ved> б) .... Ved> в) .... Ved> г) Кто печатает отчет вместе со всеми настройками?
ВВ>Хотя печатал на куче принтеров, через ахБраузер.
А что это за контрол? какая у него лицензия? Если он платный, то уже не подходт априори. У тебя в отчетах была многоколоночность с разбивкой на страницы (т. е. чтобы можно было вывести только одну какую-то страницу, или диапазон, список оных?) Причем многоколоночность такого плана:
Страница 1
Колонка 1 начало Колонка 2 начало
1 4
2 5
3 6
Колонка 1 конец Колонка 2 конец
Страница 2
Колонка 1 начало Колонка 2 начало
7 10
8 11
9 12
Колонка 1 конец Колонка 2 конец
Форматирование иной раз может быть намного более сложным...
Мне вообще интересно = ахБроузер может сказать тебе — сколько в печатной странице у него строк? Что поместится, а что нет? А если юзеру хочется поля поменять или с принтером не совпадут? Как HTML для страницы без этих параметров формировать?
ВВ>Я не против стандарта, я против, извиняюсь за каламбур, включения стандарта в стандарт. Можно работать с графом, и уже _на_основе_его_ генерить xsl:fo
Можно, зато полученный контрол для отображения на основе xsl:fo можно и отдельно использовать — весьма полезная штука получится.
ВВ>100% согласен. Я когда начинал копаться с тем же принтДокумент, у меня поначалу вызывало затруднение даже распечатке текста без разделения на строки. Но ведь никто и не говорил, что будет легко
Вообще — если писать конкретный код для конкретного отчета — все достаточно просто получается, а вот если пытаешься универсально сделать — вот тогда все и начинается
Здравствуйте, AndrewVK, Вы писали:
Ved>> г) Юзер ждет окна с внешним видом отчета. Кто его покажет? .NET или Java-вский конвертер? AVK>Ни тот и не другой, а например Acrobat Reader .
А если надо сделать так, чтобы юзер смотрел только из твоего же приложения и не мог отчет только просмотреть и не мог ни сохранить, ни распечатать, ни Ctrl+C/Ctrl+V сделать? (Print Screen не в счет, хотя в идеале и это было бы неплохо ) Или что-то в этом роде? Такое бывает очень и очень нужно (у нас например такое есть и востребовано (безопасность, так сказать)).
Кроме того, на компе у юзера Acrobat Reader'а может по каким-то причинам не быть, или еще что? Как говорится, желание юзера... Да и запускать отдельное приложение как-то неаккуратненнько получается. Тогда действительно очень хорошо было бы дополнительно сделать свой формат и самим его печатать и просматривать. А преобразования можно было бы и сторонними библиотеками выполнять. Идеально сюда мог бы вписаться еще и сервер отчетов.
Здравствуйте, AndrewVK, Вы писали:
AVK>Что то я никак тебя не пойму. То ты про входные данные, то ты про шаблоны, теперь уже про данные для отрисовки. Какая то у тебя каша получается. Итак есть вполне отдельные сущности: AVK>1) Входные данные AVK>2) Шаблон отчета AVK>3) Готовый отчет AVK>О формате чего ты речь ведешь? Какой формат должна иметь каждая из этих сущностей?
1) Ну тут все более или менее ясно. XML или можно даже напрямую использовать DataSet.
2) Насколько я понял у тебя шаблон отчета — это XML, в котором хранятся как данные, так и общие сведения о представлении. (Где будут храниться детальные сведения о представлении? — цвет границ таблицы, шрифты и пр. Также в шаблоне? Или устанавливаться для всех отчетов сразу?) Я предлагаю использовать здесь не XML, а реализовать класс ReportDocument. по типу
class ReportDocument {
StyleTableCollection Styles { get; } // Коллеция классов, в которых содержится _вся_ информация о представлении
ReportElementCollection ReportElements { get; } // Типизированная коллекция элементов документа. Все они реализуют некий интерфейс
//IElement. [Возможно, даже логика рисовать прописана непосредственно в них]
... // к-нить дополнительные данные }
3)Готовый отчет — это отчет, готовый для представления? Если так, то данное понятие вообще довольно условно. Фактически оптимально рассмотреть здесь наибольшее количество форматов. При этом желательно осуществить поддержку вывода отчета и средствами самого репортера — чтобы пользователь каждый разный акробата не запускал. А для вывода наиболее удобен (==прост) именно ХТМЛ благодаря ВебБраузеру.
ВВ>>Ну мне кажется, что ХТМЛ все же упрощает некоторые задачи — например, легко разделить данные и представления посредством CSS. AVK>И что? Зачем ее разделять в уже готовом отчете?
А ты как предлагаешь настраивать представление отчета? Суть разделения не в нем самом, конечно. А в том, что достаточно сделать нехитрый едитор/генератор CSS и внешний вид отчета будет _полностью_ настраиваемым — причем по весьма удобной модели. Т.е. непосредственно сам процесс генерации ХТМЛ будет вообще абстрагирован от всяких там цветов и рамок. Всем этим будет заниматься отдельный генератор CSS.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>1) Ну тут все более или менее ясно. XML или можно даже напрямую использовать DataSet.
То есть здесь у тебя с моим предложением расхождений нет.
ВВ>2) Насколько я понял у тебя шаблон отчета — это XML, в
XSLT
ВВ> котором хранятся как данные, так и общие сведения о представлении.
Нет там никаких данных, только представление
ВВ>(Где будут храниться детальные сведения о представлении? — цвет границ таблицы, шрифты и пр.
Вот именно там и будут
ВВ> Также в шаблоне? Или устанавливаться для всех отчетов сразу?) Я предлагаю использовать здесь не XML, а реализовать класс ReportDocument.
Зачем??? Зачем сочинять свой собственный DOM, придумывать свою собственную механику заполнения этого шаблона данными? Что ты этим получишь кроме горы работы и нестандартности решения?
ВВ>3)Готовый отчет — это отчет, готовый для представления?
Да
ВВ>Если так, то данное понятие вообще довольно условно. Фактически оптимально рассмотреть здесь наибольшее количество форматов.
А я вот предлагаю xsl:fo, а уж его стандартными средствами конвертировать в разные форматы. В твоем же случае рендерер для каждого формата фактически придется писать заново.
ВВ>При этом желательно осуществить поддержку вывода отчета и средствами самого репортера — чтобы пользователь каждый разный акробата не запускал. А для вывода наиболее удобен (==прост) именно ХТМЛ благодаря ВебБраузеру.
Он абсолютно не годится в качестве универсального решения хотя бы потому что не показывает разбиение на страницы.
AVK>>И что? Зачем ее разделять в уже готовом отчете?
ВВ>А ты как предлагаешь настраивать представление отчета?
В шаблоне.
ВВ>Суть разделения не в нем самом, конечно. А в том, что достаточно сделать нехитрый едитор/генератор CSS
А как же поддержка разных форматов?
ВВ> и внешний вид отчета будет _полностью_ настраиваемым — причем по весьма удобной модели.
Зачем настраивать вид готового отчета? Мало того что это не нужно, иногда это еще и вредно.
ВВ>Т.е. непосредственно сам процесс генерации ХТМЛ будет вообще абстрагирован от всяких там цветов и рамок. ВВ> Всем этим будет заниматься отдельный генератор CSS.
В общем плохая идея. HTML в качестве формата отчетов годится в крайне ограниченных случаях, когда не нужно точное разбиение на страницы и точное расположение элементов на странице. А вся механика о которой ты речь ведешь для других форматов будет просто не задействована.
Я имел в виду ActiveX WebBrowser — движок ИЕ. Многие проблемы с печатью он действительно решает. Есть даже готовый просмотр для страницы, можно выбирать диапазон и пр.
Здравствуйте, Ved, Вы писали:
Ved>А если надо сделать так, чтобы юзер смотрел только из твоего же приложения и не мог отчет только просмотреть и не мог ни сохранить, ни распечатать, ни Ctrl+C/Ctrl+V сделать?
А зачем такое нужно?
Ved>(Print Screen не в счет, хотя в идеале и это было бы неплохо ) Или что-то в этом роде? Такое бывает очень и очень нужно (у нас например такое есть и востребовано (безопасность, так сказать)).
Странное требование. Все равно при желании в экселе все что угодно нарисовать можно.
Ved>Кроме того, на компе у юзера Acrobat Reader'а может по каким-то причинам не быть, или еще что?
Ну значит поставит, раз нет. А ты предлагаешь фактически аналог акробата написать самостоятельно? Можно конечно, но это очень большой объем работ.
Ved>Как говорится, желание юзера... Да и запускать отдельное приложение как-то неаккуратненнько
Почему отдельное приложение? Акробат вполне втыкается в OLE контейнер и ActiveX по моему есть.
Ved> получается. Тогда действительно очень хорошо было бы дополнительно сделать свой формат и самим его печатать и просматривать.
Ну свой то зачем? Тогда уж действительно писать рендерер, рисующий прямо из fo.
Ved> А преобразования можно было бы и сторонними библиотеками выполнять. Идеально сюда мог бы вписаться еще и сервер отчетов.
Здравствуйте, AndrewVK, Вы писали:
AVK>Зачем??? Зачем сочинять свой собственный DOM, придумывать свою собственную механику заполнения этого шаблона данными? Что ты этим получишь кроме горы работы и нестандартности решения?
Кода обещает быть довольно много, соответственно нужно подумать и о дизайне. Если к примеру занимать ручной отрисовкой для отображения отчета в собственном контроле, то благодаря собственному же ДОМу можно использовать ряд интересных решений. Вот например читал я где-то, что в AutoCad все представляемые элементы строго типизированы и непосредственно в их классах содержится логика прорисовки. Довольно красивое решение имхо. К тому же такая модель будет приближена именно к конкретным нуждам.
ВВ>>3)Готовый отчет — это отчет, готовый для представления? AVK>Да ВВ>>Если так, то данное понятие вообще довольно условно. Фактически оптимально рассмотреть здесь наибольшее количество форматов.
AVK>А я вот предлагаю xsl:fo, а уж его стандартными средствами конвертировать в разные форматы. В твоем же случае рендерер для каждого формата фактически придется писать заново.
Собственным ДОМ мог бы быть просто промежуточным звеном между входящими данными и XLST. Подобный граф можно легко сериализовать, сохранив отчет в неком нативном формате. Данный граф явно не привязан ни к каком итоговому формату (пдфы, доки там всякие). И данный граф непосредственно используется при отрисовке отчета средствами самого репортера. Т.е., если полностью забить на ХТМЛ и при этом все же согласиться с тем, что встроенная поддержка просмотра должна быть, то можно построить класс ReportDocument так, что задача отрисовки максимально упростится. Таким образом получится, что отображение отчета средствами репортера != какому-либо его преобразованию.
AVK>В общем плохая идея. HTML в качестве формата отчетов годится в крайне ограниченных случаях, когда не нужно точное разбиение на страницы и точное расположение элементов на странице. А вся механика о которой ты речь ведешь для других форматов будет просто не задействована.
В принципе-то я не спорю, что использование ХТМЛ — довольно кривое решение, но уж очень оно привлекает из-за простоты в некоторых аспектах Имелось в виду, что отображаться отчет будет уметь только в формате ХТМЛ, а сохраняться — еще в ряде других.
По поводу стилей. То есть ты вообще против настраиваемости стилей в какой бы то ни было форме? Я о том, что бы пользоваль мог определить цветовые и пр. характеристики, притом, чтобы они могли ассоциироваться непосредственно с _данным_ отчетом. Модель CSS — именно модель, а не CSS в частности — соответственно, предполагает, что есть некие дефолтовые таблицы стилей, прихватываемые по умолчанию. Но есть возможность и менять их на разных уровнях.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Ved, Вы писали:
Ved>>А если надо сделать так, чтобы юзер смотрел только из твоего же приложения и не мог отчет только просмотреть и не мог ни сохранить, ни распечатать, ни Ctrl+C/Ctrl+V сделать? AVK>А зачем такое нужно?
От юзеров защита — ну понимаешь, заказчик попадается и говорит: "Надо, чтобы юзеры могли вот это, а вот это и это не могли сделать". А рисовать где-то — так на это время надо и много данных так не нарисуешь...
Ved>>(Print Screen не в счет, хотя в идеале и это было бы неплохо ) Или что-то в этом роде? Такое бывает очень и очень нужно (у нас например такое есть и востребовано (безопасность, так сказать)). AVK>Странное требование. Все равно при желании в экселе все что угодно нарисовать можно.
Можно конечно, только вот много не нарисуешь.
Ved>>Кроме того, на компе у юзера Acrobat Reader'а может по каким-то причинам не быть, или еще что? AVK>Ну значит поставит, раз нет. А ты предлагаешь фактически аналог акробата написать самостоятельно? Можно конечно, но это очень большой объем работ.
Не всегда могут согласиться поставить. Увы. А то, что это большой объем работ, так и ежу ясно. По крайней мере редактора писать не надо — разве что дизайнер отчетов.
AVK>Почему отдельное приложение? Акробат вполне втыкается в OLE контейнер и ActiveX по моему есть.
Есть. Только вот он идет с полым Acrobat'ом и денег стоит. И не понимает документов из потока, только из файла.
AVK>Ну свой то зачем? Тогда уж действительно писать рендерер, рисующий прямо из fo.
Можно. Заодно и как отдельный контрол может пользоваться бооольшим спросом.
Ved>> А преобразования можно было бы и сторонними библиотеками выполнять. Идеально сюда мог бы вписаться еще и сервер отчетов. AVK>Это имхо обязательно.
Причем единожды сформированные и хранящиеся в базе отчеты не должны иметь возможности редактирования и должны снабжаться подписью-сертификатом. Но это уже в разряд фич можно поместить.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Я имел в виду ActiveX WebBrowser — движок ИЕ. Многие проблемы с печатью он действительно решает. Есть даже готовый просмотр для страницы, можно выбирать диапазон и пр.
Я не использовал этот контрол для печати, но абстрагируясь от ослика, он не позволяет сказать точно, что на какой странице будет — разве что приблизительно, не позволяет понять, сколько же точно страниц. А выделять мышой — это, имхо, не есть хорошо — может не понравиться. Да и данные тогда оттуда выдрать можно легко будет. Да и предварительного просмотра у него нет — так, как везде в отчетах... Да, это можно попробовать сэмулировать, но по-моему, это тоже достаточно неудобно...
ВВ>Кода обещает быть довольно много, соответственно нужно подумать и о дизайне. Если к примеру занимать ручной отрисовкой для отображения отчета в собственном контроле, то благодаря собственному же ДОМу можно использовать ряд интересных решений. Вот например читал я где-то, что в AutoCad все представляемые элементы строго типизированы и непосредственно в их классах содержится логика прорисовки. Довольно красивое решение имхо. К тому же такая модель будет приближена именно к конкретным нуждам.
Я в экспериментах шел примерно таким же путем — список объектов, каждый из которых умеет отрисовываться. Главная проблема — что, где, и когда из объектов должно отрисовываться. Там могут помочь списки с событиями — по событию обрабатывается соответствующий список.
ВВ>По поводу стилей. То есть ты вообще против настраиваемости стилей в какой бы то ни было форме? Я о том, что бы пользоваль мог определить цветовые и пр. характеристики, притом, чтобы они могли ассоциироваться непосредственно с _данным_ отчетом. Модель CSS — именно модель, а не CSS в частности — соответственно, предполагает, что есть некие дефолтовые таблицы стилей, прихватываемые по умолчанию. Но есть возможность и менять их на разных уровнях.
Стили — вещь хорошая и нужная, только реализовать их тоже лучше в xml, если только не связываться с HTML'ем.
Здравствуйте, Ved, Вы писали:
Ved>Здравствуйте, Воронков Василий, Вы писали:
ВВ>>Кода обещает быть довольно много, соответственно нужно подумать и о дизайне. Если к примеру занимать ручной отрисовкой для отображения отчета в собственном контроле, то благодаря собственному же ДОМу можно использовать ряд интересных решений. Вот например читал я где-то, что в AutoCad все представляемые элементы строго типизированы и непосредственно в их классах содержится логика прорисовки. Довольно красивое решение имхо. К тому же такая модель будет приближена именно к конкретным нуждам. Ved>Я в экспериментах шел примерно таким же путем — список объектов, каждый из которых умеет отрисовываться. Главная проблема — что, где, и когда из объектов должно отрисовываться. Там могут помочь списки с событиями — по событию обрабатывается соответствующий список.
Возможно, здесь даже не будет надобности в событиях. Будет последовательный разбор документа и соответствующая отрисовка. (Если все же рисовать по собственному графу, то это легче всего сделать, как я говорил, сабклассировав PrintDocument).
ВВ>>По поводу стилей. То есть ты вообще против настраиваемости стилей в какой бы то ни было форме? Я о том, что бы пользоваль мог определить цветовые и пр. характеристики, притом, чтобы они могли ассоциироваться непосредственно с _данным_ отчетом. Модель CSS — именно модель, а не CSS в частности — соответственно, предполагает, что есть некие дефолтовые таблицы стилей, прихватываемые по умолчанию. Но есть возможность и менять их на разных уровнях. Ved>Стили — вещь хорошая и нужная, только реализовать их тоже лучше в xml, если только не связываться с HTML'ем.
Стили в предлагаемом мной варианте — это типизированная коллекция классов, к-я будет просто сериализоваься — возможно в тот же хмл. Стили будут являться частью графа.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Кода обещает быть довольно много, соответственно нужно подумать и о дизайне. Если к примеру занимать ручной отрисовкой для отображения отчета в собственном контроле, то благодаря собственному же ДОМу можно использовать ряд интересных решений. Вот например читал я где-то, что в AutoCad все представляемые элементы строго типизированы и непосредственно в их классах содержится логика прорисовки. Довольно красивое решение имхо.
И жутко негибкое. Сложно добавить новый элемент. Практически невозможно изменить целевое устройство для отрисовки.
ВВ> К тому же такая модель будет приближена именно к конкретным нуждам.
Пока что я слышу одни красивые лозунги и никаких конкретных аргументов.
AVK>>А я вот предлагаю xsl:fo, а уж его стандартными средствами конвертировать в разные форматы. В твоем же случае рендерер для каждого формата фактически придется писать заново.
ВВ>Собственным ДОМ мог бы быть просто промежуточным звеном между входящими данными и XLST.
А зачем он тогда нужен?
ВВ>Подобный граф можно легко сериализовать,
Ну да, а xml сериализовать куда сложнее.
ВВ> сохранив отчет в неком нативном формате.
Ага, чтобы никто не догадался. Знаешь, когда я слышу слова "свой формат" я тут же сильно пугаюсь, ибо велосипеды-с.
ВВ>Данный граф явно не привязан ни к каком итоговому формату (пдфы, доки там всякие).
А XSLT или XSL:FO разве привязаны? Ты пойми что изобретаешь велосипед. Xml и есть тот самый граф, только не самопальный, а стандартный и уже готовый.
ВВ>И данный граф непосредственно используется при отрисовке отчета средствами самого репортера.
Чем он будет лучше Xml DOM с содержащимся внутри него FO?
ВВ> Т.е., если полностью забить на ХТМЛ и при этом все же согласиться с тем, что встроенная поддержка просмотра должна быть, то можно построить класс ReportDocument так, что задача отрисовки максимально упростится.
Ничем она не упростится. Обработка входных данных это самый маленький кусок. Самое тяжелое в рендерере это т.н. layout engine, который от входного формата мало зависит. Рисовать же объектами, хранящими данные как раз и есть то самое смешивание данных и представления, против которого ты недавно выступал.
ВВ> Таким образом получится, что отображение отчета средствами репортера != какому-либо его преобразованию.
А зачем такое? Зачем лишние цепочки конвеера? Я вобще предполагаю что на начальном этапе вобще рендереры не делать, а использовать готовые. А потом уж, при желании, реализовать свой рендерер FO.
ВВ>В принципе-то я не спорю, что использование ХТМЛ — довольно кривое решение, но уж очень оно привлекает из-за простоты в некоторых аспектах
Форматы, в которые штатно выводит FOP:
PDF
PCL
PostScript
RTF
SVG
AWT (это вьювер, написанный на джаве)
MIF
TXT
А вот теперь прикинь сколько тебе понадобиться человеколет чтобы реализовать отрисовку в эти форматы руками.
ВВ>Имелось в виду, что отображаться отчет будет уметь только в формате ХТМЛ, а сохраняться — еще в ряде других.
То есть про отображение разбиения на страницы можно сразу забыть?
ВВ>По поводу стилей. То есть ты вообще против настраиваемости стилей в какой бы то ни было форме?
На готовых отчетах? Конечно против. А вот при рендеринге пожалуйста — все что нужно это поменять xslt-шаблоны для конкретных примитивов редактора. В разы гибче CSS.
ВВ> Я о том, что бы пользоваль мог определить цветовые и пр. характеристики, притом, чтобы они могли ассоциироваться непосредственно с _данным_ отчетом.
Зачем такое надо? И для чего стили, если все равно речь идет о конкретном документе?
ВВ>Модель CSS — именно модель, а не CSS в частности — соответственно, предполагает, что есть некие дефолтовые таблицы стилей, прихватываемые по умолчанию. Но есть возможность и менять их на разных уровнях.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, AndrewVK, Вы писали:
AVK>>Зачем??? Зачем сочинять свой собственный DOM, придумывать свою собственную механику заполнения этого шаблона данными? Что ты этим получишь кроме горы работы и нестандартности решения?
Да все то же самое. Только custom может получиться быстрее — устаешь от чужик багов.
ВВ>Кода обещает быть довольно много, соответственно нужно подумать и о дизайне. Если к примеру занимать ручной отрисовкой для отображения отчета в собственном контроле, то благодаря собственному же ДОМу можно использовать ряд интересных решений. Вот например читал я где-то, что в AutoCad все представляемые элементы строго типизированы и непосредственно в их классах содержится логика прорисовки. Довольно красивое решение имхо. К тому же такая модель будет приближена именно к конкретным нуждам.
ВВ>>>3)Готовый отчет — это отчет, готовый для представления? AVK>>Да ВВ>>>Если так, то данное понятие вообще довольно условно. Фактически оптимально рассмотреть здесь наибольшее количество форматов.
Конечно условно. Если дизайнер будет сильно зависеть от представления — это, как сказал кто-то, признак плохого дизайна
AVK>>А я вот предлагаю xsl:fo, а уж его стандартными средствами конвертировать в разные форматы. В твоем же случае рендерер для каждого формата фактически придется писать заново.
Фигня. Дело не в рендерере даже, а в том, как построить систему, чтобы не наступать везде на одни и теже грабли в виде собою же поставленных (для простоты, типа) ограничений.
ВВ>Собственным ДОМ мог бы быть просто промежуточным звеном между входящими данными и XLST. Подобный граф можно легко сериализовать, сохранив отчет в неком нативном формате. Данный граф явно не привязан ни к каком итоговому формату (пдфы, доки там всякие). И данный граф непосредственно используется при отрисовке отчета средствами самого репортера. Т.е., если полностью забить на ХТМЛ и при этом все же согласиться с тем, что встроенная поддержка просмотра должна быть, то можно построить класс ReportDocument так, что задача отрисовки максимально упростится. Таким образом получится, что отображение отчета средствами репортера != какому-либо его преобразованию.
AVK>>В общем плохая идея. HTML в качестве формата отчетов годится в крайне ограниченных случаях, когда не нужно точное разбиение на страницы и точное расположение элементов на странице. А вся механика о которой ты речь ведешь для других форматов будет просто не задействована.
Это да.
ВВ>В принципе-то я не спорю, что использование ХТМЛ — довольно кривое решение, но уж очень оно привлекает из-за простоты в некоторых аспектах Имелось в виду, что отображаться отчет будет уметь только в формате ХТМЛ, а сохраняться — еще в ряде других. ВВ>По поводу стилей. То есть ты вообще против настраиваемости стилей в какой бы то ни было форме? Я о том, что бы пользоваль мог определить цветовые и пр. характеристики, притом, чтобы они могли ассоциироваться непосредственно с _данным_ отчетом. Модель CSS — именно модель, а не CSS в частности — соответственно, предполагает, что есть некие дефолтовые таблицы стилей, прихватываемые по умолчанию. Но есть возможность и менять их на разных уровнях.
Да будет настраиваемость! Только вот не перед печатью. Хотя... разбивка на страницы, футеры и отступы — чем не настраиваемость?
P>>Здравствуйте, SiAVoL, Вы писали:
ВВ>А есть ли какие собственные идеи по поводу движка? В данном случае это вопрос первостепенной важности. Было бы интересно рассмотреть и другие варианты.
Убереги тебя Бог от всякого движка. Движки, особенно навороченные и глобальные — самое из самых зол. Давайте делать компоненты.
К примеру, есть сериализатор — и пусть он будет просто сериализатор. Без отчетов и расчетов. А всю необходимую кастомность надо вкладывать в классы расширений. ну типа SerializationBinder.
Здравствуйте, Ved, Вы писали:
Ved>От юзеров защита — ну понимаешь, заказчик попадается и говорит: "Надо, чтобы юзеры могли вот это, а вот это и это не могли сделать". А рисовать где-то — так на это время надо и много данных так не нарисуешь...
Ну такого уровня защита в PDF присутствует.
AVK>>Странное требование. Все равно при желании в экселе все что угодно нарисовать можно. Ved>Можно конечно, только вот много не нарисуешь.
А много обычно и не надо
Ved>Не всегда могут согласиться поставить. Увы.
Странно, почему это? Сейчас даже драйвера некоторые акробат ставят.
Ved>А то, что это большой объем работ, так и ежу ясно. По крайней мере редактора писать не надо — разве что дизайнер отчетов.
Ну на первых порах тот же XmlSpy сойдет.
AVK>>Почему отдельное приложение? Акробат вполне втыкается в OLE контейнер и ActiveX по моему есть. Ved>Есть. Только вот он идет с полым Acrobat'ом и денег стоит.
Да нет конечно. Ты в IE пробовал pdf открывать? И никаких полных акробатов. Попробовал сейчас кинуть ActiveX акробатовский на шарповскую форму — вроде бы тоже все работает.
Ved>И не понимает документов из потока, только из файла.
Опять же как тогда он доки из инета показывает? И что означает свойство src контрола?
AVK>>Это имхо обязательно. Ved>Причем единожды сформированные и хранящиеся в базе отчеты не должны иметь возможности редактирования и должны снабжаться подписью-сертификатом. Но это уже в разряд фич можно поместить.
Это уже детали. Главное должен быть сервер, одновременно генерящий отчеты и поддерживающий их очередь. Причем генерящий в том числе и асинхронно.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Возможно, здесь даже не будет надобности в событиях. Будет последовательный разбор документа и соответствующая отрисовка. (Если все же рисовать по собственному графу, то это легче всего сделать, как я говорил, сабклассировав PrintDocument).
Пройденный этап. Гимора и кода было более, чем достаточно. Попробуй — поймешь, о чем я. В конце концов похоронил эту идею. Реализация с событиями более гибка и позволит сделать поддержку плагинов-расширений гораздо более простой.
ВВ>Стили в предлагаемом мной варианте — это типизированная коллекция классов, к-я будет просто сериализоваься — возможно в тот же хмл. Стили будут являться частью графа.
А почему бы не сделать по примеру CSS? CSS разбирать не совсем удобно, а свой xml было бы попроще... И делать на него ссылки? При надобности можно его внедрять в шаблон — эдакий гибрид CSS и твоего предложения? Просто использование глобального шаблона позволит менять стили всех шаблонов. Если этого не надо — внедрять в шаблон и все.
Здравствуйте, AndrewVK, Вы писали:
AVK>Да нет конечно. Ты в IE пробовал pdf открывать? И никаких полных акробатов. Попробовал сейчас кинуть ActiveX акробатовский на шарповскую форму — вроде бы тоже все работает.
Пробовал, только вот в ослика не контрол подгружается, а сам ридер как сервер автоматизации. Точно так же ведет себя и Word — а ведь у него уж точно контрола нет.
Ved>>И не понимает документов из потока, только из файла.
AVK>Опять же как тогда он доки из инета показывает? И что означает свойство src контрола?
Temporary Internet Files. Но зарекаться не буду — с контролом не работал, попробую на выходных.
Здравствуйте, Ved, Вы писали:
Ved>Пробовал, только вот в ослика не контрол подгружается, а сам ридер как сервер автоматизации.
Ну я ж написал что два варианта.
Ved>Точно так же ведет себя и Word — а ведь у него уж точно контрола нет.
Да. Но у акробата и контрол есть.
AVK>>Опять же как тогда он доки из инета показывает? И что означает свойство src контрола? Ved>Temporary Internet Files.
Вряд ли, потому что акробат запускается сразу, не дожидаясь закачки.
AVK>И жутко негибкое. Сложно добавить новый элемент. Практически невозможно изменить целевое устройство для отрисовки.
А для этого существует двойная диспетчеризация и все довольно красиво получается — и элемент добавляется только в лет
AVK>Пока что я слышу одни красивые лозунги и никаких конкретных аргументов.
Эта точна... где Розовая модель.
AVK>>>А я вот предлагаю xsl:fo, а уж его стандартными средствами конвертировать в разные форматы. В твоем же случае рендерер для каждого формата фактически придется писать заново.
ВВ>>Собственным ДОМ мог бы быть просто промежуточным звеном между входящими данными и XLST.
AVK>А зачем он тогда нужен?
Чиста для использования памяти — чтоб не простоивала
AVK>Ну да, а xml сериализовать куда сложнее.
Эта точно
AVK>А XSLT или XSL:FO разве привязаны? Ты пойми что изобретаешь велосипед. Xml и есть тот самый граф, только не самопальный, а стандартный и уже готовый.
И w3c о нем знает
AVK>Ничем она не упростится. Обработка входных данных это самый маленький кусок. Самое тяжелое в рендерере это т.н. layout engine, который от входного формата мало зависит. Рисовать же объектами, хранящими данные как раз и есть то самое смешивание данных и представления, против которого ты недавно выступал.
Ну не данные, а ссылки на них наверное в стилевом контексте.
ВВ>>В принципе-то я не спорю, что использование ХТМЛ — довольно кривое решение, но уж очень оно привлекает из-за простоты в некоторых аспектах
Это полный пи... при получении WISIWIG
AVK>Форматы, в которые штатно выводит FOP: AVK>PDF AVK>PCL AVK>PostScript AVK>RTF AVK>SVG AVK>AWT (это вьювер, написанный на джаве) AVK>MIF AVK>TXT
AVK>А вот теперь прикинь сколько тебе понадобиться человеколет чтобы реализовать отрисовку в эти форматы руками.
Столько не живут
ВВ>>По поводу стилей. То есть ты вообще против настраиваемости стилей в какой бы то ни было форме?
AVK>На готовых отчетах? Конечно против. А вот при рендеринге пожалуйста — все что нужно это поменять xslt-шаблоны для конкретных примитивов редактора. В разы гибче CSS.
При дизайне в самый раз — поменял стиль и все сломалось А вообще идея здравая.
AVK>Зачем такое надо? И для чего стили, если все равно речь идет о конкретном документе?
Наверное можно предусмотреть библиотеки стилей, а если еще сделать контекстность стиля от данных — например с привязкай скрипта.
AVK>XSLT гибче
И намного.
P>>>Здравствуйте, SiAVoL, Вы писали:
ВВ>>А есть ли какие собственные идеи по поводу движка? В данном случае это вопрос первостепенной важности. Было бы интересно рассмотреть и другие варианты.
P>Убереги тебя Бог от всякого движка. Движки, особенно навороченные и глобальные — самое из самых зол. Давайте делать компоненты. P>К примеру, есть сериализатор — и пусть он будет просто сериализатор. Без отчетов и расчетов. А всю необходимую кастомность надо вкладывать в классы расширений. ну типа SerializationBinder.
Речь о реализации след:
1)Входящие данные
2)Шаблон отчета
3)Готовый отчет (представление)
Покамест договорились только о том, что входящие данные — это хмл | датасет.
Здравствуйте, Ved, Вы писали:
Ved>Здравствуйте, Воронков Василий, Вы писали:
ВВ>>Возможно, здесь даже не будет надобности в событиях. Будет последовательный разбор документа и соответствующая отрисовка. (Если все же рисовать по собственному графу, то это легче всего сделать, как я говорил, сабклассировав PrintDocument). Ved>Пройденный этап. Гимора и кода было более, чем достаточно. Попробуй — поймешь, о чем я. В конце концов похоронил эту идею. Реализация с событиями более гибка и позволит сделать поддержку плагинов-расширений гораздо более простой.
Уточни детально в чем гимор, в чем грабли. Как никак была же реализация на подобной модели. И что предполагает модель событий? Где размещать код отрисовки? Мне вот просто нравится сама идея, что код для отрисовки элемента непосредственно в самом классе элемента. Удобно. "Пройденный этап" относится и к предложению сабклассировать PrintDocument? Если да, то тоже уточни.
ВВ>>Стили в предлагаемом мной варианте — это типизированная коллекция классов, к-я будет просто сериализоваься — возможно в тот же хмл. Стили будут являться частью графа. Ved>А почему бы не сделать по примеру CSS? CSS разбирать не совсем удобно, а свой xml было бы попроще... И делать на него ссылки? При надобности можно его внедрять в шаблон — эдакий гибрид CSS и твоего предложения? Просто использование глобального шаблона позволит менять стили всех шаблонов. Если этого не надо — внедрять в шаблон и все.
Ну что значит "свой хмл"? Он откуда берется? Сериализуется? Если да, то из экземпляра к-нить класса наверное? Или просто с нуля создается?
Я вот не совсем понял — ты за или против использования в качестве шаблона графа объектов, а не XSLT, как предлагает АВК? Если да, то тут самый простой и логичный вариант сделать стили частью графа, а там уж сериализовать их как мы захотим. При этом так же можно будет добавлять и просто "ссылки" на стандартные стили и внедрять кастом стили в шаблон.
Здравствуйте, AndrewVK, Вы писали:
ВВ>>Кода обещает быть довольно много, соответственно нужно подумать и о дизайне. Если к примеру занимать ручной отрисовкой для отображения отчета в собственном контроле, то благодаря собственному же ДОМу можно использовать ряд интересных решений. Вот например читал я где-то, что в AutoCad все представляемые элементы строго типизированы и непосредственно в их классах содержится логика прорисовки. Довольно красивое решение имхо. AVK>И жутко негибкое. Сложно добавить новый элемент.
Почему?
AVK>Практически невозможно изменить целевое устройство для отрисовки.
Дык это и не нужно.
ВВ>> К тому же такая модель будет приближена именно к конкретным нуждам. AVK>Пока что я слышу одни красивые лозунги и никаких конкретных аргументов.
Собственную ст-ру будет значительно проще изменять; можно разместить в ней уже некоторую логику по типу как я выше предложил.В моем случае ситуация такова: получаем ДатаСет, на основе его создаем граф, куда так же помещает инфа о стилях + "метаданные" репорта (ну там фигня всякая). Данный граф может сериализоваться. Вьювер репорта может непосредственно работать с графом.
AVK>>>А я вот предлагаю xsl:fo, а уж его стандартными средствами конвертировать в разные форматы. В твоем же случае рендерер для каждого формата фактически придется писать заново. ВВ>>Собственным ДОМ мог бы быть просто промежуточным звеном между входящими данными и XLST. AVK>А зачем он тогда нужен?
Отображение отчета и преобразование его в ряд форматов — не одно и то же. Мне как пользователю сабжа может потребоваться например только отображение. Соответственно, логично и сам код соответствующим образом представить. Хуже-то точно не будет. ( )А вот отрисовку делать, работая с собственным графом значительно проще. Его можно хоть раком поставить. События к-нить впихнуть нужные и проч., ту же логику отрисовки. Каждый элемент репорта, представленный в графе, будет соответственно разработан именно как элемент репорта, т.е. максимально оптимизирован под отрисовку и многое другое. Будет куда легче вносить к-либо изменения, сабж станет куда более масштабируемым. Твой вариант просто приводит к уменьшению объемов кодирования, но всегда ли это гуд?
ВВ>>Подобный граф можно легко сериализовать, AVK>Ну да, а xml сериализовать куда сложнее.
ВВ>> сохранив отчет в неком нативном формате. AVK>Ага, чтобы никто не догадался. Знаешь, когда я слышу слова "свой формат" я тут же сильно пугаюсь, ибо велосипеды-с.
Ну и где здесь велосипед? Пара строк для сериализации?
ВВ>>Данный граф явно не привязан ни к каком итоговому формату (пдфы, доки там всякие). AVK>А XSLT или XSL:FO разве привязаны? Ты пойми что изобретаешь велосипед. Xml и есть тот самый граф, только не самопальный, а стандартный и уже готовый.
А как расширить XML? Именно как DOM как его расширить? XML — это уже готовый ДОМ.
ВВ>> Т.е., если полностью забить на ХТМЛ и при этом все же согласиться с тем, что встроенная поддержка просмотра должна быть, то можно построить класс ReportDocument так, что задача отрисовки максимально упростится. AVK>Ничем она не упростится. Обработка входных данных это самый маленький кусок. Самое тяжелое в рендерере это т.н. layout engine, который от входного формата мало зависит. Рисовать же объектами, хранящими данные как раз и есть то самое смешивание данных и представления, против которого ты недавно выступал.
Можно подумать о других вариантах. Но вся соль-то как раз в том, что здесь есть возможность над ними подумать, модифицировать соответствующим образом граф и пр.
ВВ>> Таким образом получится, что отображение отчета средствами репортера != какому-либо его преобразованию. AVK>А зачем такое? Зачем лишние цепочки конвеера? Я вобще предполагаю что на начальном этапе вобще рендереры не делать, а использовать готовые. А потом уж, при желании, реализовать свой рендерер FO.
Возможность отображения отчета средствами репортера не менее важна, чем его сохранение в приведенный тобой форматах. Не вижу оснований, почему на нее надо сначала забить, и использовать что-либо готовое? (В чужом коде копаться? Думаешь, это мало времени займет? И при этом все ради того, чтобы потом забить на этот чужой код и писать свой -нелогично как-то). Стандартная работа с репортером такова: После генерения отчета он сначала _показывается_ пользовалю, а затем уже — по желанию пользователя — сохраняется в некий формат. Исходя из такой цепочки логично даже сначала реализовать рендер, а затем конвертер.
[skipped about HTML]
Ну ХТМЛ пролетает, понятно. Я сразу написал, что мне самому не слишком импонирует данный вариант. Но все же стоит обсудить все варианты.
ВВ>>По поводу стилей. То есть ты вообще против настраиваемости стилей в какой бы то ни было форме? AVK>На готовых отчетах? Конечно против. А вот при рендеринге пожалуйста — все что нужно это поменять xslt-шаблоны для конкретных примитивов редактора. В разы гибче CSS.
На готовых отчетах ну нужно конечно. Твой вариант — ты предлагаешь, чтобы можно было настраивать представления "точечно", для каждого примитива, а не для всего документа? Не слишком ли муторно? Да и нужна ли такая детализация?
ВВ>> Я о том, что бы пользоваль мог определить цветовые и пр. характеристики, притом, чтобы они могли ассоциироваться непосредственно с _данным_ отчетом. AVK>Зачем такое надо? И для чего стили, если все равно речь идет о конкретном документе?
Стили могут быть стандартный, те общие для всех документов. Может быть также и возможность создания специального стиля для данного документа, который есно будет сохраняться непосредственно как часть документа.
Здравствуйте, Poudy, Вы писали:
AVK>>>Зачем??? Зачем сочинять свой собственный DOM, придумывать свою собственную механику заполнения этого шаблона данными? Что ты этим получишь кроме горы работы и нестандартности решения? P>Да все то же самое. Только custom может получиться быстрее — устаешь от чужик багов.
ОК, значит ты меня поддерживаешь.
ВВ>>>>Если так, то данное понятие вообще довольно условно. Фактически оптимально рассмотреть здесь наибольшее количество форматов. P>Конечно условно. Если дизайнер будет сильно зависеть от представления — это, как сказал кто-то, признак плохого дизайна
Вроде бы дизайнер мы пока не обсуждали...
ВВ>>Собственным ДОМ мог бы быть просто промежуточным звеном между входящими данными и XLST. Подобный граф можно легко сериализовать, сохранив отчет в неком нативном формате. Данный граф явно не привязан ни к каком итоговому формату (пдфы, доки там всякие). И данный граф непосредственно используется при отрисовке отчета средствами самого репортера. Т.е., если полностью забить на ХТМЛ и при этом все же согласиться с тем, что встроенная поддержка просмотра должна быть, то можно построить класс ReportDocument так, что задача отрисовки максимально упростится. Таким образом получится, что отображение отчета средствами репортера != какому-либо его преобразованию. AVK>>>В общем плохая идея. HTML в качестве формата отчетов годится в крайне ограниченных случаях, когда не нужно точное разбиение на страницы и точное расположение элементов на странице. А вся механика о которой ты речь ведешь для других форматов будет просто не задействована. P>Это да.
ОК, на ХТМЛ забиваем, хотя конвертер писать для него все равно потом нуно будет.
ВВ>>В принципе-то я не спорю, что использование ХТМЛ — довольно кривое решение, но уж очень оно привлекает из-за простоты в некоторых аспектах Имелось в виду, что отображаться отчет будет уметь только в формате ХТМЛ, а сохраняться — еще в ряде других. ВВ>>По поводу стилей. То есть ты вообще против настраиваемости стилей в какой бы то ни было форме? Я о том, что бы пользоваль мог определить цветовые и пр. характеристики, притом, чтобы они могли ассоциироваться непосредственно с _данным_ отчетом. Модель CSS — именно модель, а не CSS в частности — соответственно, предполагает, что есть некие дефолтовые таблицы стилей, прихватываемые по умолчанию. Но есть возможность и менять их на разных уровнях. P>Да будет настраиваемость! Только вот не перед печатью. Хотя... разбивка на страницы, футеры и отступы — чем не настраиваемость?
Перед печатью не нужно есно. При рендеринге только. А перед печатью — всякая фигня с футерами, как ты и сказал.
Здравствуйте, AndrewVK, Вы писали: AVK>>>Почему отдельное приложение? Акробат вполне втыкается в OLE контейнер и ActiveX по моему есть. Ved>>Есть. Только вот он идет с полым Acrobat'ом и денег стоит. AVK>Да нет конечно. Ты в IE пробовал pdf открывать? И никаких полных акробатов. Попробовал сейчас кинуть ActiveX акробатовский на шарповскую форму — вроде бы тоже все работает.
Adobe does not support or license development using the Acrobat ActiveX (OCX)
component that ships with Acrobat and Acrobat Reader. Its purpose is to integrate
with Internet Explorer. Adobe has no documentation available regarding ActiveX
(OCX) development with Acrobat.
Использование ридера для отображения pdf в своем приложении запрещено лицензионными соглашением. Увы.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, Poudy, Вы писали:
P>>>>Здравствуйте, SiAVoL, Вы писали:
ВВ>>>А есть ли какие собственные идеи по поводу движка? В данном случае это вопрос первостепенной важности. Было бы интересно рассмотреть и другие варианты.
P>>Убереги тебя Бог от всякого движка. Движки, особенно навороченные и глобальные — самое из самых зол. Давайте делать компоненты. P>>К примеру, есть сериализатор — и пусть он будет просто сериализатор. Без отчетов и расчетов. А всю необходимую кастомность надо вкладывать в классы расширений. ну типа SerializationBinder.
ВВ>Речь о реализации след:
ВВ>1)Входящие данные ВВ>2)Шаблон отчета ВВ>3)Готовый отчет (представление)
ВВ>Покамест договорились только о том, что входящие данные — это хмл | датасет.
Понятно. Только давайте забудем про C++ и все что там еще, и не будем заниматься вот этим вот : "формат шаблона", "стандартные форматы представления", "хорошая связь с базой данных" и т.д. Как и почти в любом другом деле, все можно собрать из независимых компонентов. Т.е. на самом деле компонентов, как OpenFileDialog. Согласен?
Здравствуйте, Воронков Василий, Вы писали:
AVK>>И жутко негибкое. Сложно добавить новый элемент.
ВВ>Почему?
Ну как почему? У тебя получается каждый элемент твоего дерева хранит как данные так и представление. В связи с чем все стандартные проблемы такого подхода — сложность изменения представления и структуры данных, высокая связность.
AVK>>Практически невозможно изменить целевое устройство для отрисовки.
ВВ>Дык это и не нужно.
Вот я бы так не был уверен.
ВВ>Собственную ст-ру будет значительно проще изменять;
А xsl:fo дерево вобще изменять не нужно.
ВВ>можно разместить в ней уже некоторую логику по типу как я выше предложил.
Можно, но зачем? MVC уже не рулит?
ВВ>В моем случае ситуация такова: получаем ДатаСет, на основе его создаем граф,
Зачем из датасета создавать граф, если он сам уже граф? Зачем вобще из входных данных создавать граф? По моему ты опять начинаешь путать шаблон отчета и входные данные.
ВВ>куда так же помещает инфа о стилях + "метаданные" репорта (ну там фигня всякая).
Ну то есть данные и представление в одном флаконе? По моему ты сам себе противоречишь.
ВВ>Данный граф может сериализоваться. Вьювер репорта может непосредственно работать с графом.
Все это хорошо ты говоришь, но я тебя наверное в третий раз уже спрашиваю — в чем преимущества твоего графа перед xsl:fo? Или нет, лучше так — какие недостатки xsl:fo тебе удастся устранить своим графом?
ВВ>>>Собственным ДОМ мог бы быть просто промежуточным звеном между входящими данными и XLST. AVK>>А зачем он тогда нужен?
ВВ>Отображение отчета и преобразование его в ряд форматов — не одно и то же.
Ну как тебе сказать — вот в FOP это одно и то же. Собственно говоря набор команд GDI-устройства это такой же графический формат.
ВВ>Мне как пользователю сабжа может потребоваться например только отображение. Соответственно, логично и сам код соответствующим образом представить. Хуже-то точно не будет. ( )
Будет. Лишние сущности, усложнение архитектуры, лишняя работа, лишние глюки, необходимость проверять отображение как во вьювере, так и в целевом выводе.
ВВ>А вот отрисовку делать, работая с собственным графом значительно проще.
Ну чем проще то? Чем?
ВВ>Его можно хоть раком поставить.
Опять одни слова. Давай конкретно — вот такая то возможность твоим графом реализуется так то, а граф xsl:fo позволяет реализовать только вот так.
ВВ> События к-нить впихнуть нужные
Какие?
ВВ>и проч., ту же логику отрисовки. Каждый элемент репорта, представленный в графе, будет соответственно разработан именно как элемент репорта,
Опять ты начинаешь путать. Элемент репорта это одно, а вот элемент отображения это немножко иное.
ВВ>т.е. максимально оптимизирован под отрисовку
Вот это совсем плохо. Оптимизировать структу3ры репорта надо не под отрисовку, а под использование их пользователем.
ВВ>и многое другое. Будет куда легче вносить к-либо изменения,
Сложнее.
ВВ>сабж станет куда более масштабируемым.
Значительно менее.
ВВ>Твой вариант просто приводит к уменьшению объемов кодирования, но всегда ли это гуд?
Практически всегда. Кроме того мой вариант использует стандарты, а значит более понятен и способен взаимодействовать с другими продуктами куда легче.
AVK>>Ага, чтобы никто не догадался. Знаешь, когда я слышу слова "свой формат" я тут же сильно пугаюсь, ибо велосипеды-с.
ВВ>Ну и где здесь велосипед? Пара строк для сериализации?
Нет, велосипед в том что если кому то захочется напрямую прочитать файл шаблона то он обломается по полной программе.
AVK>>А XSLT или XSL:FO разве привязаны? Ты пойми что изобретаешь велосипед. Xml и есть тот самый граф, только не самопальный, а стандартный и уже готовый.
ВВ>А как расширить XML?
Зачем его расширять?
ВВ>Именно как DOM как его расширить? XML — это уже готовый ДОМ.
Ну и чем он тебя не устраивает?
ВВ>Можно подумать о других вариантах. Но вся соль-то как раз в том, что здесь есть возможность над ними подумать, модифицировать соответствующим образом граф и пр.
Слушай, ну давай ты перестанешь туммаными фразами кидаться, ОК? Опять какие то мифические модификации. Ну как об этом можно говорить если непонятно о чем речь идет?
AVK>>А зачем такое? Зачем лишние цепочки конвеера? Я вобще предполагаю что на начальном этапе вобще рендереры не делать, а использовать готовые. А потом уж, при желании, реализовать свой рендерер FO.
ВВ>Возможность отображения отчета средствами репортера не менее важна,
Чем?
ВВ>чем его сохранение в приведенный тобой форматах. Не вижу оснований, почему на нее надо сначала забить,
Потому что тот же акробат ридер весьма неплохо с этим справляется. Я понимаю что тебе очень хочется написать именно вьювер, но зачем его писать если он уже написан?
ВВ> и использовать что-либо готовое?
Мда, мне даже сказать нечего. Действительно, зачем использовать готовое?
ВВ>(В чужом коде копаться? Думаешь, это мало времени займет?
Ты лучше избавляйся от желания переписать все и вся Для охлаждения пыла могу посоветовать скачать исходники FOP и прикинуть сколько времени у тебя займет разработка аналога.
ВВ>И при этом все ради того, чтобы потом забить на этот чужой код и писать свой
Кто сказал?
ВВ> -нелогично как-то). Стандартная работа с репортером такова: После генерения отчета он сначала _показывается_ пользовалю, а затем уже — по желанию пользователя — сохраняется в некий формат.
Ссылку на стандарт в студию
AVK>>На готовых отчетах? Конечно против. А вот при рендеринге пожалуйста — все что нужно это поменять xslt-шаблоны для конкретных примитивов редактора. В разы гибче CSS.
ВВ>На готовых отчетах ну нужно конечно.
Зачем? Давай ситуацию опиши когда такое надо.
ВВ>Твой вариант — ты предлагаешь, чтобы можно было настраивать представления "точечно", для каждого примитива, а не для всего документа?
Зачем? xslt позволяет инклюдить другие файлы, использовать внешние переменные и много чего другого. Технология xslt полностью перекрывает возможности CSS в плане изоляции представления.
AVK>>Зачем такое надо? И для чего стили, если все равно речь идет о конкретном документе?
ВВ>Стили могут быть стандартный, те общие для всех документов. Может быть также и возможность создания специального стиля для данного документа, который есно будет сохраняться непосредственно как часть документа.
Но это все обеспечивается выбором стиля на этапе генерации. Для этого совершенно нет никакой необходимости менять стили на уже сгенерированном отчете.
Здравствуйте, AndrewVK, Вы писали:
ВВ>>Собственную ст-ру будет значительно проще изменять; AVK>А xsl:fo дерево вобще изменять не нужно.
Проект-то опенсурс, могут возникнуть самые разные задачи для модификации.
ВВ>>можно разместить в ней уже некоторую логику по типу как я выше предложил. AVK>Можно, но зачем? MVC уже не рулит?
Имхо это не лучшее решение для дизайна. MVC больше подходит для работы с динамическим представлениям; у нас же стоит задача проведения одно цикла отрисовки, причем никаких изменений с результатом отрисовки уже проводиться не будет.
AVK>Опять одни слова. Давай конкретно — вот такая то возможность твоим графом реализуется так то, а граф xsl:fo позволяет реализовать только вот так.
Я не понимаю, как xslf — да собственно вообще самый процесс XSL Formatting — поможет мне в gdi-отрисовке.
AVK>Вот это совсем плохо. Оптимизировать структу3ры репорта надо не под отрисовку, а под использование их пользователем.
А как пользователь их будет использовать? Документ репортера по идее — статическая штука, его составляющие можно даже скрыть от пользователя в принципе.
AVK>Слушай, ну давай ты перестанешь туммаными фразами кидаться, ОК? Опять какие то мифические модификации. Ну как об этом можно говорить если непонятно о чем речь идет?
Речь идет об отрисовке опять-таки. Думаю, многие со мной согласятся в том, что наличие вьювера весьма сильно повысит привлекательность репортера. А так как кода обещает быть много, то надо сразу подумать о том, как проектировать отрисовку. Вариант с собственным графом — хотя он и может поначалу показаться лишним шагом по созданию одного графа из другого — просто даст в этом плане большую гибкость. Я привел один вариант, как можно использовать собст. граф для отрисовке (когда об отрисовке элемента репорта знает только сам этот элемент).Возможно этот вариант и не идеален, но он показывает ту гибкость, к-й можно достичь если использовать свой граф.
AVK>Потому что тот же акробат ридер весьма неплохо с этим справляется. Я понимаю что тебе очень хочется написать именно вьювер, но зачем его писать если он уже написан?
Требуется вьювер, который можно непосредственно располагать на форма. по аналогии с crystal report viewer.
AVK>Ты лучше избавляйся от желания переписать все и вся Для охлаждения пыла могу посоветовать скачать исходники FOP и прикинуть сколько времени у тебя займет разработка аналога.
Ну понятно. Если бы я сам мог это сделать дня за два, так уж и сделал бы давно. Если два-три человека еще займутся отрисовкой, то все будет не так уж и страшно.
ВВ>>И при этом все ради того, чтобы потом забить на этот чужой код и писать свой AVK>Кто сказал?
Ты сам говорил, что _поначалу_ можно использовать готовый рендерер, а потом написать свой.
ВВ>> -нелогично как-то). Стандартная работа с репортером такова: После генерения отчета он сначала _показывается_ пользовалю, а затем уже — по желанию пользователя — сохраняется в некий формат. AVK>Ссылку на стандарт в студию
Глумишься, да? Я описываю стандартную работу пользователя рендера. Документ сначала показывается — а потом уж отправляется в файл, на печать и пр. Пользователь так или иначе не сможет уйти от этого промежуточного шага. Что ему, акробат загружать? Сделав свою отрисовку, мы по сути подарим пользователю full managed control, с помощью которого он сможет без лишнего гемора показывать отчет юзеру.
AVK>>>На готовых отчетах? Конечно против. А вот при рендеринге пожалуйста — все что нужно это поменять xslt-шаблоны для конкретных примитивов редактора. В разы гибче CSS. ВВ>>На готовых отчетах ну нужно конечно. AVK>Зачем? Давай ситуацию опиши когда такое надо.
На готовых отчетах не нужно конечно. Забавная опечатка вышла.
Здравствуйте, Poudy, Вы писали:
P>Понятно. Только давайте забудем про C++ и все что там еще, и не будем заниматься вот этим вот : "формат шаблона", "стандартные форматы представления", "хорошая связь с базой данных" и т.д. Как и почти в любом другом деле, все можно собрать из независимых компонентов. Т.е. на самом деле компонентов, как OpenFileDialog. Согласен?
Ничего не понял. Как ты собираешься забыть о шаблоне репорта? Тут обсуждение идет, каким он должен быть — я предлагаю использовать собст. граф, АВК — xls. Да и что ты собираешь собрать из независимых компонентов? У нас стоят две генеральные задачи — отрисовка и конвертация. Какие компоненты тут могут тебе помочь?
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, Poudy, Вы писали:
P>>Понятно. Только давайте забудем про C++ и все что там еще, и не будем заниматься вот этим вот : "формат шаблона", "стандартные форматы представления", "хорошая связь с базой данных" и т.д. Как и почти в любом другом деле, все можно собрать из независимых компонентов. Т.е. на самом деле компонентов, как OpenFileDialog. Согласен?
ВВ>Ничего не понял. Как ты собираешься забыть о шаблоне репорта? Тут обсуждение идет, каким он должен быть — я предлагаю использовать собст. граф, АВК — xls. Да и что ты собираешь собрать из независимых компонентов? У нас стоят две генеральные задачи — отрисовка и конвертация. Какие компоненты тут могут тебе помочь?
Я исхож у из того, что системная куча — это и есть граф объектов. Не надо никакого реморроя по поводу конкретного шаблона. IMHO, в каждом конкретном случае необходимо использовать то представление, которое удобнее. И писать врапперы вместо конвертеров.
Ну, к примеру, файл с данными не должен зависеть от типов созданных нами объектов (цвета там, настройки, линии). Значит это либо XML, либо еще что такое, независимое от типа. По первой кажется, что вот мы щас напишем много классов с публичными свойствами и будет это у нас дерево шаблона, а потом мы его ррраз и в XML сериализуем. А потом назад, то-то будет зае..сь. Мне кажется это утопия. Уродовать модель, лишь бы убогими MS методами она потом в файл сложилась.
Я не говорю, что ты именно так предлагаешь, я говорю, что так не нужно. Т.е. нужены отдельно сборщик SerializationInfo и отдельно сериализатор пофиг куда. И чтобы назад из десериализованного SerializationInfo поднимать типы по желанию. Т.е. генерировать разные представления по загруженным данным. Восстанавливать и в контролы и в картинку. Я так думаю не оттого, что струкрура плохо продумана, а оттого, что это в разы проще и дешевле — не смешивать функциональность. Как маньяк порежу класс на восемь штук, лишь бы поделить между ними ответственность.
Сейчас AndrewVK скажет, что это все наивно и тухло, писать самому и "с нуля" (не пойму, почему с нуля-то всё?), но я откровенно не понимаю, как он будет редактировать xls. Если везде придется писать xls.properties["color"], то... , а если все такие вещи обернуть свойствами, то принципиально это мало отличается от разных там графов.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Проект-то опенсурс,
Первый раз такое слышу
ВВ>могут возникнуть самые разные задачи для модификации.
Ты не мудри, ты пальцем покажи что за такие задачи, что ты не сможешь их описать в терминах xslt и xsl:fo?
AVK>>Можно, но зачем? MVC уже не рулит?
ВВ>Имхо это не лучшее решение для дизайна.
Одно из лучших для систем, занимающихся отображением данных
ВВ>MVC больше подходит для работы с динамическим представлениям; у нас же стоит задача проведения одно цикла отрисовки, причем никаких изменений с результатом отрисовки уже проводиться не будет.
У нас стоит задача отображения данных. Это основное назначение MVC.
AVK>>Опять одни слова. Давай конкретно — вот такая то возможность твоим графом реализуется так то, а граф xsl:fo позволяет реализовать только вот так.
ВВ>Я не понимаю, как xslf — да собственно вообще самый процесс XSL Formatting — поможет мне в gdi-отрисовке.
Что значит поможет? FO это описание способа, которым нужно отрисовать некие данные, некий аналог HTML, но только значительно мощнее. Вот собственно и все.
ВВ>А как пользователь их будет использовать? Документ репортера по идее — статическая штука, его составляющие можно даже скрыть от пользователя в принципе.
Опять я тебя перестаю понимать. Ты с такой легкостью перескакиваешь с данных на шаблон, с шаблона на результат что я уже не пойму к чему относится твой граф. Ты уж определись.
ВВ>Речь идет об отрисовке опять-таки. Думаю, многие со мной согласятся в том, что наличие вьювера весьма сильно повысит привлекательность репортера.
А ты не боишься просто его не сделать?
ВВ> А так как кода обещает быть много, то надо сразу подумать о том, как проектировать отрисовку.
Ну да, а на остальное нам плевать? Ты все таки репортер хочешь сделать, или тебе интересен исключительно вьювер?
И кому нужен вьювер, который отображает какие то проприетарные форматы входных данных, жутко неудобные для всего остального, кроме отрисовки?
ВВ>Вариант с собственным графом — хотя он и может поначалу показаться лишним шагом по созданию одного графа из другого — просто даст в этом плане большую гибкость.
Просто чтоб была?
ВВ>Возможно этот вариант и не идеален, но он показывает ту гибкость, к-й можно достичь если использовать свой граф.
Да нет там никакой гибкости. Ты просто намешал все в одну кучу.
ВВ>Требуется вьювер, который можно непосредственно располагать на форма. по аналогии с crystal report viewer.
И больше ничего не требуется? Главное вьювер?
AVK>>Ты лучше избавляйся от желания переписать все и вся Для охлаждения пыла могу посоветовать скачать исходники FOP и прикинуть сколько времени у тебя займет разработка аналога.
ВВ>Ну понятно. Если бы я сам мог это сделать дня за два, так уж и сделал бы давно. Если два-три человека еще займутся отрисовкой, то все будет не так уж и страшно.
Блин, лень тебе посмотреть. Хорошо, скажу так — архив исходников FOP это 7М. Это не 2-3 человека, это человек 10 и 1-2 года работы.
ВВ>>>И при этом все ради того, чтобы потом забить на этот чужой код и писать свой AVK>>Кто сказал?
ВВ>Ты сам говорил, что _поначалу_ можно использовать готовый рендерер, а потом написать свой.
Потом я имел ввиду если очень захочется и чем то не устроит FOP. Я по прежнему считаю что портирование FOPа значительно более правильное решение, нежели написание своего аналога.
Да, FOP это не столько конвертер, сколько рендерер FO. То есть как раз то что ты так жаждешь написать.
ВВ>>> -нелогично как-то). Стандартная работа с репортером такова: После генерения отчета он сначала _показывается_ пользовалю, а затем уже — по желанию пользователя — сохраняется в некий формат. AVK>>Ссылку на стандарт в студию
ВВ>Глумишься, да?
Почему? Просто не надо рассказывать про стандарты. Я видел репортеры, где было все совсем не так.
ВВ> Я описываю стандартную работу пользователя рендера.
Пользователя? При чем тут пользователь? Какая ему разница что, где и в какой последовательности происходит внутрях программы? Ему главное результат.
ВВ>Документ сначала показывается — а потом уж отправляется в файл, на печать и пр.
Нет никакой разницы между показыванием и отправкой на печать. И то и то вывод на устройство отображения. Все репортеры, которые я видел, в том числе и те, которые я сам писал работали именно так.
Здравствуйте, Poudy, Вы писали:
P>Я исхож у из того, что системная куча — это и есть граф объектов. Не надо никакого реморроя по поводу конкретного шаблона. IMHO, в каждом конкретном случае необходимо использовать то представление, которое удобнее. И писать врапперы вместо конвертеров.
Что такое "системная куча"? Что ты подразумеваешь под представлением для каждого конкретного случая? Врапперы над чем?
Ты слишком общо пишешь, будь конкретней плз
P>Ну, к примеру, файл с данными не должен зависеть от типов созданных нами объектов (цвета там, настройки, линии).
Файл с какими данными? Если это данные, _совершенно_ не зависящие от "цветов" и пр., то они ничем не будут отличаться от входящих данных.
P>>Значит это либо XML, либо еще что такое, независимое от типа. По первой кажется, что вот мы щас напишем много классов с публичными свойствами и будет это у нас дерево шаблона, а потом мы его ррраз и в XML сериализуем. А потом назад, то-то будет зае..сь.
Вообще, когда назад — это называется десериализация.
P>Я не говорю, что ты именно так предлагаешь, я говорю, что так не нужно. Т.е. нужены отдельно сборщик SerializationInfo и отдельно сериализатор пофиг куда.
Что будет собирать этот сборщик?
P>Сейчас AndrewVK скажет, что это все наивно и тухло, писать самому и "с нуля" (не пойму, почему с нуля-то всё?), но я откровенно не понимаю, как он будет редактировать xls. Если везде придется писать xls.properties["color"], то... , а если все такие вещи обернуть свойствами, то принципиально это мало отличается от разных там графов.
Здравствуйте, AndrewVK, Вы писали:
ВВ>>Проект-то опенсурс, AVK> Первый раз такое слышу
А какой тогда? Опенсурс в моем понимании — это когда человек может зайти сайт, увидеть, что ведется разработка такого-то проека и присоединиться к разработчикам, если есть желание/возможность. Ну по идее и код должен быть доступен для публичного скачивания.
ВВ>>могут возникнуть самые разные задачи для модификации. AVK>Ты не мудри, ты пальцем покажи что за такие задачи, что ты не сможешь их описать в терминах xslt и xsl:fo?
Ну мы уже по кругу идем.
Я сейчас скажу, что может потребоваться изменить ДОМ-модель.
Ты скажешь, а нафиг ее менять.
Я скажу, что это может потребоваться для облегчения отрисовки.
Ты скажешь, а нафиг самим писать отрисовку.
Собственно, все мои предложения исходят только из того допущеня, что отрисовку мы будем писать сами. А если нет, то никакой граф нафиг не нужен.
AVK>>>Можно, но зачем? MVC уже не рулит? ВВ>>Имхо это не лучшее решение для дизайна. AVK>Одно из лучших для систем, занимающихся отображением данных ВВ>>MVC больше подходит для работы с динамическим представлениям; у нас же стоит задача проведения одно цикла отрисовки, причем никаких изменений с результатом отрисовки уже проводиться не будет. AVK>У нас стоит задача отображения данных. Это основное назначение MVC.
Имхо MVC больше подходит для отображения динамических изменений. Если есть к примеру некий класс, в нем происх. изменения, нужно оповещать обзервер об этих изменениях и пр. В случае с прорисовкой такого вообще не будет. Оповещение произойдет один раз и начнется рендеринг. И по-прежнему остается непонятно, как лучше размещать собственно код отрисовки для каждого отдельного элемента.
ВВ>>А как пользователь их будет использовать? Документ репортера по идее — статическая штука, его составляющие можно даже скрыть от пользователя в принципе. AVK>Опять я тебя перестаю понимать. Ты с такой легкостью перескакиваешь с данных на шаблон, с шаблона на результат что я уже не пойму к чему относится твой граф. Ты уж определись.
Кстати, возникает вопрос, как изначально будут храниться данные стиля? Так или иначе будет предполагать некая библиотека базовых стилей и тп. Что, тоже xsl? В таком случае я бы предложил пойти на компромис и минимизировать задачу графа, т.е. сделать его _только_ коллекцией стилей. Что выгодно, особенно, если в будущем потребует реализовать визуальный дизайн стилей.
ВВ>>Речь идет об отрисовке опять-таки. Думаю, многие со мной согласятся в том, что наличие вьювера весьма сильно повысит привлекательность репортера. AVK>А ты не боишься просто его не сделать?
Тут ничего особо сложного нетю Просто объемы работы большие.
ВВ>> А так как кода обещает быть много, то надо сразу подумать о том, как проектировать отрисовку. AVK>Ну да, а на остальное нам плевать? Ты все таки репортер хочешь сделать, или тебе интересен исключительно вьювер? AVK>И кому нужен вьювер, который отображает какие то проприетарные форматы входных данных, жутко неудобные для всего остального, кроме отрисовки?
Все остальное не менее, если не более важно, чем вьювер. Только непонятно, почему следует на него забивать.
AVK>Нет никакой разницы между показыванием и отправкой на печать. И то и то вывод на устройство отображения. Все репортеры, которые я видел, в том числе и те, которые я сам писал работали именно так.
Да, но в реализации-то будет капитальная разница. В этом-то и смысл логического разделения вывода на отображения и конвертацией.
Дайти плиз ссылку, где валяется архив исходников FOP.
Пока Вы тут будете спорить я займуся делом .
Ну если интересно, мое мнение по дискуссии, так чисто для статистики и без коментариев
позиция AVK для меня намного предподчтительнее и красивше.
Я бы так и делал.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>А какой тогда?
Это надо обсуждать с теми кто хочет учавствовать
AVK>>Ты не мудри, ты пальцем покажи что за такие задачи, что ты не сможешь их описать в терминах xslt и xsl:fo?
ВВ>Ну мы уже по кругу идем.
Вот именно. Сколько я не пытаюсь от тебя добится конкретики слышу только общие слова — мол будет круто.
ВВ>Я сейчас скажу, что может потребоваться изменить ДОМ-модель. ВВ>Ты скажешь, а нафиг ее менять.
Правильно скажу. Потому что нет никакого смысла обсуждать гипотетические моменты. DOM-модель это не цель, это всего лишь средство.
ВВ>Я скажу, что это может потребоваться для облегчения отрисовки.
Докажи
ВВ>Собственно, все мои предложения исходят только из того допущеня, что отрисовку мы будем писать сами. А если нет, то никакой граф нафиг не нужен.
Даже если писать отрисовку самим то все равно непонятно чем тебя не устраивает XmlDOM c содержащимся в нем xsl:fo. Если начинать со вьювера то тем более формат данных вьювера должен быть стандартен, иначе этот вьювер будет вещью в себе.
AVK>>У нас стоит задача отображения данных. Это основное назначение MVC.
ВВ>Имхо MVC больше подходит для отображения динамических изменений.
Кто сказал? Для всего оно подходит, просто в отсутствие изменений буковку С реализовывать не нужно.
ВВ> Если есть к примеру некий класс, в нем происх. изменения, нужно оповещать обзервер об этих изменениях
Какой обзервер? MVC это Model-View-Controller, нет там никаких обсерверов, ты чего то путаешь.
ВВ>Кстати, возникает вопрос, как изначально будут храниться данные стиля? Так или иначе будет предполагать некая библиотека базовых стилей и тп. Что, тоже xsl?
Почему бы нет? Точнее даже наверное не xsl а некий xml с описанием стилей. xslt шаблон может работать с несколькими xml-документами. Фактически стили будут такими же входными данными, другим потоком.
ВВ> В таком случае я бы предложил пойти на компромис и минимизировать задачу графа, т.е. сделать его _только_ коллекцией стилей. Что выгодно, особенно, если в будущем потребует реализовать визуальный дизайн стилей.
Опять ничего не понятно. Что тебе загорелось свой граф обязательно реализовывать?
AVK>>А ты не боишься просто его не сделать?
ВВ>Тут ничего особо сложного нетю Просто объемы работы большие.
Я тебе, как человек который этим занимался могу сказать — много там сложностей и проблем.
AVK>>И кому нужен вьювер, который отображает какие то проприетарные форматы входных данных, жутко неудобные для всего остального, кроме отрисовки?
ВВ>Все остальное не менее, если не более важно, чем вьювер. Только непонятно, почему следует на него забивать.
Забивать не надо, надо обеспечить возможность использовать вьювер без репортера и репортер без вьювера.
ВВ>Да, но в реализации-то будет капитальная разница.
Нет. layout manager, самое сложное, будет один и тот же. Разным будет только исполнительное устройство — GDI (экран, принтер), файл какого то формата.
ВВ>В этом-то и смысл логического разделения вывода на отображения и конвертацией.
Нету такого смысла, только лишнее дублирование кода.
Здравствуйте, Poudy, Вы писали:
P>Сейчас AndrewVK скажет, что это все наивно и тухло, писать самому и "с нуля" (не пойму, почему с нуля-то всё?), но я откровенно не понимаю, как он будет редактировать xls.
При чем тут Эксель? Если ты об XSLT то есть редакторы, а если хочешь визуально то надо писать свой дизайнер. А какая альтернатива?
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, Poudy, Вы писали:
P>>Я исхож у из того, что системная куча — это и есть граф объектов. Не надо никакого реморроя по поводу конкретного шаблона. IMHO, в каждом конкретном случае необходимо использовать то представление, которое удобнее. И писать врапперы вместо конвертеров.
ВВ>Что такое "системная куча"? Что ты подразумеваешь под представлением для каждого конкретного случая? Врапперы над чем? ВВ>Ты слишком общо пишешь, будь конкретней плз
Хор. Постараюсь.
P>>Ну, к примеру, файл с данными не должен зависеть от типов созданных нами объектов (цвета там, настройки, линии).
ВВ>Файл с какими данными? Если это данные, _совершенно_ не зависящие от "цветов" и пр., то они ничем не будут отличаться от входящих данных.
Да, входные данные. Только под "цветами" я имел в виду не то, что во входных данных нет информации о цветах. Я имел в виду, что файл должен читаться вне зависимости от конкретных System.Type. Ну не совпала версия класса "Цвет" — и хер с ним. Если сказать еще точнее, то хочется сделать так : в файле лежит нечто, именованное Report.Line. Это Report.Line не означает тип "Report.Line", и может быть десериализовано как в RSDN.Drawing.Line, так и в RSDN.GUI.LineControl. Понятно, что не прямо десериализовано, т.е. чтобы имена у свойств/полей были одинаковые. Нужно позволить расширять систему десериализации настроечными классами.
P>>>Значит это либо XML, либо еще что такое, независимое от типа. По первой кажется, что вот мы щас напишем много классов с публичными свойствами и будет это у нас дерево шаблона, а потом мы его ррраз и в XML сериализуем. А потом назад, то-то будет зае..сь.
ВВ>Вообще, когда назад — это называется десериализация.
Вот типа я не знаю. Не надо подкалывать .
P>>Я не говорю, что ты именно так предлагаешь, я говорю, что так не нужно. Т.е. нужены отдельно сборщик SerializationInfo и отдельно сериализатор пофиг куда.
ВВ>Что будет собирать этот сборщик?
Данные об объектах. Так же как это делает стандартный Formatter. Собрать необходимые данные и сложить в SerializationInfo.
P>>Сейчас AndrewVK скажет, что это все наивно и тухло, писать самому и "с нуля" (не пойму, почему с нуля-то всё?), но я откровенно не понимаю, как он будет редактировать xls. Если везде придется писать xls.properties["color"], то... , а если все такие вещи обернуть свойствами, то принципиально это мало отличается от разных там графов.
ВВ>И в итоге получится не что иное как граф объектов
Ну конечно. Ничего другого и не получится. Я когда про "системная куча" писал, это и имел в виду. Блин, все объекты работающей программы свалены в кучу, а связи между ними образуют граф. Я про это. Что бы мы не писали, даже если мы будем очень уверены, что это DataSet, т.е. типа набор строк и пр., на деле это будет граф объектов и танцовать с бубном вокруг этой деи не надо.
Ничего из того что я пишу я не пытаюсь противопоставить твоим постам. Все нормально, я со всем согласен. Я пытаюсь писать о реализации этого дела, только видимо неконкретно слишком.
Я ничего нового не хочу сказать. Только о том, что надо проводить декомпозицию по функциональности. Ну про врапперы, к примеру. Вместо того, чтобы при отрисовке в foreach'ах ходить по дереву, преобразую контролы или еще там что в IPrintableObject, можно написать врапперы над контролами, которые вследствие этого сразу окажутся выровненными и layout как надо. И родители известны и пр.
К примеру, свойство Parent такого враппера:
public IPrintableObject Parent
{
get
{
return EditingService.Current.ControlToIPrintableObject[this.Control.Parent];
}
set
{
... // всякие проверки;this.Control.Parent = EditingService.Current.IPrintableObjectToControl[value];
}
}
Это тоже все неконкретно, но все же. Просто я в шоке от того, как вы с AndrewVK спорите шут знает из-за чего. Как будто нет способов реализовать большую часть функциональности не вспоминая про формат хранения на диске.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Poudy, Вы писали:
P>>Сейчас AndrewVK скажет, что это все наивно и тухло, писать самому и "с нуля" (не пойму, почему с нуля-то всё?), но я откровенно не понимаю, как он будет редактировать xls.
AVK>При чем тут Эксель?
Действительно, и при чем тут лопата.
AVK>Если ты об XSLT то есть редакторы, а если хочешь визуально то надо писать свой дизайнер. А какая альтернатива?
Выхода действительно нет. Только при чем тут тогда сам XSLT? Ведь не один текст же править в дизайнере?
Здравствуйте, Poudy, Вы писали:
AVK>>Если ты об XSLT то есть редакторы, а если хочешь визуально то надо писать свой дизайнер. А какая альтернатива? P>Выхода действительно нет. Только при чем тут тогда сам XSLT?
Стандарт.
P>Ведь не один текст же править в дизайнере?
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Poudy, Вы писали:
AVK>>>Если ты об XSLT то есть редакторы, а если хочешь визуально то надо писать свой дизайнер. А какая альтернатива? P>>Выхода действительно нет. Только при чем тут тогда сам XSLT?
AVK>Стандарт.
Очень хорошо. На самом деле. Только дизайнер не должен зависеть ни от xslt, ни от html, смертным боем стоять буду. Если под каждый язык писать заново редактор, никаких ресурсов не зватит. Или я не прав?
P>>Ведь не один текст же править в дизайнере?
AVK>Ну для начала можно ограничиться и текстом.
В общем да. Но я уже накалывался на таком — лучше забыть про "для начала" и сразу делать нормально. Иначе много переписывать приходится только ради того, чтобы убедиться в том, что схема работает.
Здравствуйте, Poudy, Вы писали:
P>Очень хорошо. На самом деле. Только дизайнер не должен зависеть ни от xslt, ни от html,
Не понял, при чем здесь html? Речь идет о дизайнере шаблонов.
AVK>>Ну для начала можно ограничиться и текстом. P>В общем да. Но я уже накалывался на таком — лучше забыть про "для начала" и сразу делать нормально. Иначе много переписывать приходится только ради того, чтобы убедиться в том, что схема работает.
Ну это просто наверное от того что ты изначально не учитывал возможность дизайнера.
В противном случае утонув в дизайнере можно вобще не дойти до финиша.
Здравствуйте, AndrewVK, Вы писали:
AVK>Не понял, при чем здесь html? Речь идет о дизайнере шаблонов.
И я о нем же. Или ты предполагаешь создавать шаблоны в текстовом режиме? IMHO стремно.
AVK>Ну это просто наверное от того что ты изначально не учитывал возможность дизайнера. AVK>В противном случае утонув в дизайнере можно вобще не дойти до финиша.
Резонно.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Poudy, Вы писали:
AVK>>>Не понял, при чем здесь html? Речь идет о дизайнере шаблонов. P>>И я о нем же.
AVK>Тогда при чем тут html?
Хмм.. Давай определимся. Итак, в твоих терминах шаблон — это нечто, настраивающее внешний вид либо уже готового документа (заполненного), либо еще не заполненного. Если нет, поправь меня. Если да, то это никому не нужно. Т.к. в таком виде производить полезные настройки очень тяжело. Под полезными я понимаю такие: "расположение суммы к оплате так, чтоб она влезла в рамку их готового бланка", "...на первом листе должно быть не более пяти записей..", "..вот эта линия должна быть жирненькой.."(заметь, это видимо стиль линии lsCrossLine, который будет лежать в xslt, как я понимаю, т.е. xsl:fo не помогут)
На самом деле я не отвергаю этот подход, но считаю что он покрывает от силы 10% нужд и одним им не обойдешься.
Здравствуйте, Poudy, Вы писали:
AVK>>Тогда при чем тут html? P>Хмм.. Давай определимся. Итак, в твоих терминах шаблон — это нечто, настраивающее внешний вид либо уже готового документа (заполненного),
Нет. В моих терминах шаблон это правила, которые описывают как получить из входных данных печатный документ.
Здравствуйте, AndrewVK, Вы писали:
AVK>Я предлагаю использовать в качестве шаблонов xslt, преобразующий некий определенный xml в xsl:fo
Ну не знаю.. А как же C#? В xslt, конечно, много всяких фич. Тут http://www.developerfusion.com/show/89/7/ написано, что есть все, что надо. Стоит подумать.
Здравствуйте, AndrewVK, Вы писали:
ВВ>>Я скажу, что это может потребоваться для облегчения отрисовки. AVK>Докажи
Я не могу сейчас привести никаких конкретных примеров, потому что, собственно, ничего конкретного-то пока и нет. По большому счету я просто ратую за изменяемость как за принципиальное св-во системы. XmlDOM всем хорош, но я не смогу приспособить его под конкретные нужды. Я старался привести какие-то примеры — с той же логикой отрисовки непосредственно в графе — когда использование собственной DOM модели даст большую гибкость, позволит реализовать нестандартные дизайнерские решения и пр. Фактически реализация собственного графа не приведет к сильному "утяжелению" логику. Его можно воспринимать как своеобразный враппер над XML. Более того, "клиентский" код, работающий с графом, выиграет в плане читабельности, тк разбирать его будет проще, чем XmlDOM, тк он будет оптимизирован под конкретные нужды. Если народ считает, что это не нужно, то бог с ним. Только вот я не пойму как-то, в чем я тут не прав?
ВВ>> Если есть к примеру некий класс, в нем происх. изменения, нужно оповещать обзервер об этих изменениях AVK>Какой обзервер? MVC это Model-View-Controller, нет там никаких обсерверов, ты чего то путаешь.
Ну что view, что observer — один фиг. Принцип-то тот же. В джаве есть даже интерфейсик специальный, к-й каждый view реализует — java.util.Observer.
ВВ>> В таком случае я бы предложил пойти на компромис и минимизировать задачу графа, т.е. сделать его _только_ коллекцией стилей. Что выгодно, особенно, если в будущем потребует реализовать визуальный дизайн стилей. AVK>Опять ничего не понятно. Что тебе загорелось свой граф обязательно реализовывать?
Наверняка же надо будет осуществить возможность создания и редакции стилей в дизайн-тайме юзером и что-то подобное. Наиболее удобный способ редакции — проперти грид.
AVK>>>А ты не боишься просто его не сделать? ВВ>>Тут ничего особо сложного нетю Просто объемы работы большие. AVK>Я тебе, как человек который этим занимался могу сказать — много там сложностей и проблем.
Да верю я, верю. Вьювером можно и в самом конце заняться. Просто не хотелось бы оказаться в такой ситуации, что, приступив к работе над вьювером, обнаруживаешь, что в сущ. архитектуру он не особо-то хорошо влезает. Т.е. ты вот пишешь: "кому нужен вьювер, который отображает какие то проприетарные форматы входных данных, жутко неудобные для всего остального, кроме отрисовки?". А не может ли получиться наоборот? Т.е. "удобные для всего остального, кроме отрисовки"?
ВВ>>Все остальное не менее, если не более важно, чем вьювер. Только непонятно, почему следует на него забивать. AVK>Забивать не надо, надо обеспечить возможность использовать вьювер без репортера и репортер без вьювера.
Ну что ж, не спорю. Т.е. фактически получается, что вьювер выступает в роли этакового универсального рендерера FO?
Здравствуйте, Poudy, Вы писали:
ВВ>>Файл с какими данными? Если это данные, _совершенно_ не зависящие от "цветов" и пр., то они ничем не будут отличаться от входящих данных. P>Да, входные данные. Только под "цветами" я имел в виду не то, что во входных данных нет информации о цветах. Я имел в виду, что файл должен читаться вне зависимости от конкретных System.Type. Ну не совпала версия класса "Цвет" — и хер с ним. Если сказать еще точнее, то хочется сделать так : в файле лежит нечто, именованное Report.Line. Это Report.Line не означает тип "Report.Line", и может быть десериализовано как в RSDN.Drawing.Line, так и в RSDN.GUI.LineControl. Понятно, что не прямо десериализовано, т.е. чтобы имена у свойств/полей были одинаковые. Нужно позволить расширять систему десериализации настроечными классами.
Расширять == добавлять новые элементы репорта? Вообще это можно сделать и сохранив привязку к конкретным System.Type.
P>>>>Значит это либо XML, либо еще что такое, независимое от типа. По первой кажется, что вот мы щас напишем много классов с публичными свойствами и будет это у нас дерево шаблона, а потом мы его ррраз и в XML сериализуем. А потом назад, то-то будет зае..сь. ВВ>>Вообще, когда назад — это называется десериализация. P>Вот типа я не знаю. Не надо подкалывать .
Ну а чего ж ты пишешь-то? Когда вперед — это сериализация. Когда назад — зае..сь. Явно тут у тебя какая-то путаница в терминах.
P>>>Я не говорю, что ты именно так предлагаешь, я говорю, что так не нужно. Т.е. нужены отдельно сборщик SerializationInfo и отдельно сериализатор пофиг куда. ВВ>>Что будет собирать этот сборщик? P>Данные об объектах. Так же как это делает стандартный Formatter. Собрать необходимые данные и сложить в SerializationInfo.
Хм, что-то мне это дело трудно сейчас переварить. Поздно уже наверное.
ВВ>>И в итоге получится не что иное как граф объектов P>Ну конечно. Ничего другого и не получится. Я когда про "системная куча" писал, это и имел в виду. Блин, все объекты работающей программы свалены в кучу, а связи между ними образуют граф.
Да, почти так. Только на самом деле здесь скорее типичный случай фабрики — "куча объектов" это на самом деле абстрактные классы, а создавать их можно через саму фабрику. Граф же фабрикой не является, он также объект из кучи. Но общий подход понятен.
P>Я про это. Что бы мы не писали, даже если мы будем очень уверены, что это DataSet, т.е. типа набор строк и пр., на деле это будет граф объектов и танцовать с бубном вокруг этой деи не надо.
Вот, собственно, я это и пытаюсь протолкнуть, а народ сопротивляется. Придумаешь, _железный_ аргумент в защиту такого варианта?
P>Я ничего нового не хочу сказать. Только о том, что надо проводить декомпозицию по функциональности. Ну про врапперы, к примеру. Вместо того, чтобы при отрисовке в foreach'ах ходить по дереву, преобразую контролы или еще там что в IPrintableObject, можно написать врапперы над контролами, которые вследствие этого сразу окажутся выровненными и layout как надо. И родители известны и пр. P>К примеру, свойство Parent такого враппера:
P>
P>Это тоже все неконкретно, но все же. Просто я в шоке от того, как вы с AndrewVK спорите шут знает из-за чего. Как будто нет способов реализовать большую часть функциональности не вспоминая про формат хранения на диске.
На самом деле-то мы спорим как раз из-за этого. Я-то и предлагаю использовать собственную DOM-модель, а не XmlDOM, но АВК считает, что это ничего не даст, кроме лишнего кода, лишних багов и пр.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Vitaton, Вы писали:
V>>Дайти плиз ссылку, где валяется архив исходников FOP. V>>Пока Вы тут будете спорить я займуся делом .
AVK>xml.apache.org/fop
AVK>Но сначала посмотри
AVK>sourceforge.net/projects/nfop
Н-да. Я впервые в жизни увидел такую кучу джава-кода. И что с этим делать? Только на изучение исходников неделя уйдет. Да и документации нормальной нет. Мы это просто использовать будем без изменений или как?
Здравствуйте, Poudy, Вы писали:
AVK>>Я предлагаю использовать в качестве шаблонов xslt, преобразующий некий определенный xml в xsl:fo P>Ну не знаю.. А как же C#? В xslt, конечно, много всяких фич. Тут http://www.developerfusion.com/show/89/7/ написано, что есть все, что надо. Стоит подумать.
А подумав еще немного я понял: чтобы довести это дело до визуального "чего-нибудь" придется солидно попотеть.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, Poudy, Вы писали:
ВВ>Расширять == добавлять новые элементы репорта? Вообще это можно сделать и сохранив привязку к конкретным System.Type.
Нет. Расширять — это добавлять функциональность ничего не переписывая и не дописывая кода в готовые классы. Я имею в виду OpenClosed Principle.
ВВ>Вот, собственно, я это и пытаюсь протолкнуть, а народ сопротивляется. Придумаешь, _железный_ аргумент в защиту такого варианта?
Наврядли. Если цель — настоять на своей точке зрения, то логика в аргументации не обязательна. Если ипользовать прагматичный подход, то темой беседы становится не свое (i.e. глючное) или чужое (i.e. проверенное), а применимое или нет, способное решить или не всегда, логичное или со своими заклинаниями.
Я очень даже не поддерживаю идею о том, что официальный софт лучше. И на лучшие аргументы "за" у меня есть свои контраргументы:
• :"их" софт протестирован -> :только в coomonly used случаях, если пользовать "нестандартно" или, что чаще, пользовать на полную катушку, то, даже не выходя за рамки reference, можно накопать червей.
• :да, ошибки есть, но они известны -> :нет, они известны только в тех применениях, где данный софт использовался. Если делать не клон чужого продукта, а создавать свой, найдутся неизвестные ошибки.
• :известны оптимальные решения и методы пременения -> :это так, но применимо к написанию окошечек и хранимых процедур гораздо в большей степени, чем к исследованиям и проектированию с неполными пребованиями. поэтому на деле такой аргумент всего лишь предположение. чаще именно так и есть, а используемые той в среде "методы применения" — это набор из 5-ти полезных, но элементарных вещей, и еще 183 правила для особых случаев, затыкающих баги и ограничения.
• :продвижением и развитием софта будут заниматься другие люди -> :это единственный по-настоящему сильный аргумент. и хотя мы не можем создавать свой продукт с учетом неизвестных будущих фишек используемой технологии, есть шанс получить бонус когда-то потом, за счет того, что были одними из первых.
ВВ>На самом деле-то мы спорим как раз из-за этого. Я-то и предлагаю использовать собственную DOM-модель, а не XmlDOM, но АВК считает, что это ничего не даст, кроме лишнего кода, лишних багов и пр.
Решить помогут внятные требования. Требования в студию!
Здравствуйте, Poudy, Вы писали:
P>А подумав еще немного я понял: чтобы довести это дело до визуального "чего-нибудь" придется солидно попотеть.
Визуальные дизайнеры это вобще штука сложная. И что самое неприятное, по большому счету они нужны только не имеющим в использовании конкретного продукта опыта. При наличии опыта невизуальные тулзы оказываются как правило удобнее.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Н-да. Я впервые в жизни увидел такую кучу джава-кода. И что с этим делать? Только на изучение исходников неделя уйдет.
Ага, написать все с нуля конечно быстрее
ВВ>Да и документации нормальной нет.
Как это нет? Там на сайте апачевском более менее приличная дока была.
ВВ>Мы это просто использовать будем без изменений или как?
Смотреть надо. Без изменений вряд ли портануть получится — что то придется менять, что то отбрасывать.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Я не могу сейчас привести никаких конкретных примеров, потому что, собственно, ничего конкретного-то пока и нет.
Тогда не приводи какие то непонятные мысли в качестве аргументов.
ВВ> По большому счету я просто ратую за изменяемость как за принципиальное св-во системы. XmlDOM всем хорош, но я не смогу приспособить его под конкретные нужды.
Ты сам себе противоречишь. Приспособить под конкретные нужны значит сделать неуниверсальным, значит в дальнейшем поиметь гимор с изменением уже готового кода. Стандарт подобен готовому фундаменту — вместо укрепления грунта можно сразу приступить к строительству дома.
ВВ>Я старался привести какие-то примеры — с той же логикой отрисовки непосредственно в графе
А что примеры? Ты даже не удосужился сказать чем это будет лучше.
ВВ>- когда использование собственной DOM модели даст большую гибкость,
Ну не вижу я пока никакой гибкости, вижу точно противоположное — проприетарный формат, который будет тормозом в эволюции проекта, поскольку будет заточен под конкретику и неуниверсален.
ВВ> позволит реализовать нестандартные дизайнерские решения
Какие? Опять одни слова непонятно о чем. Так программы не пишут.
ВВ>и пр. Фактически реализация собственного графа не приведет к сильному "утяжелению" логику. Его можно воспринимать как своеобразный враппер над XML.
Зачем он нужен? Просто так, на всякий случай?
ВВ>Более того, "клиентский" код, работающий с графом, выиграет в плане читабельности,
Проиграет, так как читающему придется разбираться с самопальным форматом.
ВВ>тк он будет оптимизирован под конкретные нужды.
То есть неуниверсален?
ВВ> Если народ считает, что это не нужно, то бог с ним. Только вот я не пойму как-то, в чем я тут не прав?
Я не пойму в чем ты прав. Ты в куче писем не привел никакой конкретики, одна вода. Давайте сделаем то, не знаю что, затем, не знаю зачем, ну просто чтобы было круто.
AVK>>Опять ничего не понятно. Что тебе загорелось свой граф обязательно реализовывать?
ВВ>Наверняка же надо будет осуществить возможность создания и редакции стилей в дизайн-тайме юзером и что-то подобное. Наиболее удобный способ редакции — проперти грид.
А при чем тут твой граф? Слушай, ты все таки разберись что куда. То тебе граф нужен для отрисовки, теперь уже граф нужен для отображения шаблонов. Я уже устал постоянно тебя просить разобраться что и куда ты хочешь. Давай так — ты внятно, по пунктам, с нормальным обоснованием, спримерами распишешь как ты видишь цепочку преобразования входных данных в конечный документ. А то ты сам себе постоянно противоречишь.
AVK>>Я тебе, как человек который этим занимался могу сказать — много там сложностей и проблем.
ВВ>Да верю я, верю. Вьювером можно и в самом конце заняться. Просто не хотелось бы оказаться в такой ситуации, что, приступив к работе над вьювером, обнаруживаешь, что в сущ. архитектуру он не особо-то хорошо влезает.
Вьювер не должен влезать в какую то архитектуру. Вьювер должен кушать на входе результат работы FO-рендерера и просто показывать его на экране. Собственно формат данных, с которыми будет работать вьювер в процессе непосредственно отрисовки не играет рояли. Это может быть к примеру тот же набор команд GDI + список страниц. Главное то что вьювер не должен сам заниматься рендерингом изображения, так как это самая сложная часть и она должна быть одной и для вьювера, и для печати и для вывода в файлы различных форматов. Написание рендерера это очень сложная задача, сложнее написания браузера html к примеру, поэтому я и предложил использовать готовый, то есть FOP.
Когда я говорю о приспособлении под конкретные нужды, то имеется в виду, что возможности графа будут ограничены "тематикой" проекта. На фиг нужна какая-то универсальность по отношению ко всему? Никто не заставляет тебя отказываться от стандарта. Я лишь говорю о стандартном подходе к проектированию — благодаря реализации графа не будет четкой привязки ни к ФОП (что разумеется не искл. его использование), ни к чему либо иному; к графу можно будет "прикрутить" что угодно, и при этом измнений в клиентском коде практически не будет.
Хотя вряд ли сейчас имеет смысл обсуждать это более подробно. Лучше постараться четко сформулировать список базовых задач — возможно, тогда ситуация как раз и прояснится.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Когда я говорю о приспособлении под конкретные нужды, то имеется в виду, что возможности графа будут ограничены "тематикой" проекта. На фиг нужна какая-то универсальность по отношению ко всему? Никто не заставляет тебя отказываться от стандарта. Я лишь говорю о стандартном подходе к проектированию
Здравствуйте, AndrewVK, Вы писали:
AVK>Я вобще уже не понимаю о чем ты говоришь.
Я говорю о том, что сначала надо определиться какая функциональность является базовой, а какая вторичной, и следовательно, на нее можно поначалу забить. Исходя из этого уже определить, насколько помогут исходники ФОПа, а что так или иначе придется писать самим.
Здравствуйте, AndrewVK, Вы писали:
AVK>Визуальные дизайнеры это вобще штука сложная. И что самое неприятное, по большому счету они нужны только не имеющим в использовании конкретного продукта опыта. При наличии опыта невизуальные тулзы оказываются как правило удобнее.
Шут его знает. Что-то это сомнительно. Реадктор форм в студии явно удобнее, чем InitializeComponent(). Да и HTML-редакторы тоже классные. Другое дело, что они ориентированы больше на новичка. Однако ж никто не мешает добавить в них функциональность, более подходящую искушенному пользователю. По-моему так.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Уточни детально в чем гимор, в чем грабли. Как никак была же реализация на подобной модели. И что предполагает модель событий? Где размещать код отрисовки? Мне вот просто нравится сама идея, что код для отрисовки элемента непосредственно в самом классе элемента. Удобно. "Пройденный этап" относится и к предложению сабклассировать PrintDocument? Если да, то тоже уточни.
Гимор в жесткой логике, а не в том, что каждый объект должен уметь сам сабя отрисовать в заданных пределах, с этим-то как раз все ок. Понадобится тебе ввести новый какой-то объект в отчет — и что, переделывать код, дописывать? Гораздо проще сделать модель плагинов и отрисовывать все через события (смотрим, что за объект должен отрисоваться и посылаем событие, что такой-то должен отрисоваться). Гимор — без событий.
ВВ>>>Стили в предлагаемом мной варианте — это типизированная коллекция классов, к-я будет просто сериализоваься — возможно в тот же хмл. Стили будут являться частью графа.
Но еще стили должны быть отделяемыми — чтобы один и тот же стиль мог использоваться в разных отчетах. Лучше делать на него ссылки из дерева. А во время работы — делать граф стиля и граф объекта и при отрисовке передавать объекту нужный элемент стиля.
ВВ>Ну что значит "свой хмл"? Он откуда берется? Сериализуется? Если да, то из экземпляра к-нить класса наверное? Или просто с нуля создается? ВВ>Я вот не совсем понял — ты за или против использования в качестве шаблона графа объектов, а не XSLT, как предлагает АВК? Если да, то тут самый простой и логичный вариант сделать стили частью графа, а там уж сериализовать их как мы захотим. При этом так же можно будет добавлять и просто "ссылки" на стандартные стили и внедрять кастом стили в шаблон.
Мой взгляд на это — отчеты должны быть быстрыми, мощными и удобными, с достаточными возможностями. А как это будет достигнуто — это уже второй вопрос. И если это делать под .NET, то и писать лучше по возможности все на нем же. Если XSLT обеспечит это(производительность и ресурсоемкость) — прекрасно. И еще — на мой взгляд, от xslt и xsl:fo не надо отказываться — но если это не даст нужной производительности и будет кушать слишком много ресурсов — место этому в модуле экспорта.
Здравствуйте, Ved, Вы писали:
Ved>Гимор в жесткой логике, а не в том, что каждый объект должен уметь сам сабя отрисовать в заданных пределах, с этим-то как раз все ок. Понадобится тебе ввести новый какой-то объект в отчет — и что, переделывать код, дописывать? Гораздо проще сделать модель плагинов и отрисовывать все через события
Тогда давай обозначим более обще — не события, а колбеки, поскольку вариант с неким интерфейсом, которыЙ нужно реализовать имхо будет более правильным.
Здравствуйте, AndrewVK, Вы писали:
AVK>Тогда давай обозначим более обще — не события, а колбеки, поскольку вариант с неким интерфейсом, которыЙ нужно реализовать имхо будет более правильным.
А какая межу ними разница? Имхо, в названии
Скажем так, когда отчету надо будет отрисовать такой-то текст, от скажет: "Эй, текст такой-то, отрисуй себя!"
Здравствуйте, Ved, Вы писали:
AVK>>Тогда давай обозначим более обще — не события, а колбеки, поскольку вариант с неким интерфейсом, которыЙ нужно реализовать имхо будет более правильным. Ved>А какая межу ними разница? Имхо, в названии
Колбек более общее определение.
Ved>Скажем так, когда отчету надо будет отрисовать такой-то текст, от скажет: "Эй, текст такой-то, отрисуй себя!"
Мне идея с отрисовкой самого себя не очень нравится. Я то предлагал на вход некоему примитиву отдавать относящийся к нему xml с параметрами, а на выходе ждать xsl:fo. Таким образом разработка собственно плагинов существенно упростится, поскольку не нужно будет заморачиваться особенностями отрисовывающего движка, в каждом элементе поддерживать разбиение на страницы и т.д.
Здравствуйте, AndrewVK, Вы писали:
AVK>Мне идея с отрисовкой самого себя не очень нравится. Я то предлагал на вход некоему примитиву отдавать относящийся к нему xml с параметрами, а на выходе ждать xsl:fo. Таким образом разработка собственно плагинов существенно упростится, поскольку не нужно будет заморачиваться особенностями отрисовывающего движка, в каждом элементе поддерживать разбиение на страницы и т.д.
Можно и так. Это уже детали реализации. Но это если делать предварительный промотр тоже на основе xsl:fo.
Здравствуйте, AndrewVK, Вы писали:
AVK>Мне идея с отрисовкой самого себя не очень нравится. Я то предлагал на вход некоему примитиву отдавать относящийся к нему xml с параметрами, а на выходе ждать xsl:fo. Таким образом разработка собственно плагинов существенно упростится, поскольку не нужно будет заморачиваться особенностями отрисовывающего движка, в каждом элементе поддерживать разбиение на страницы и т.д.
Какие в таком случае будут предложения по проектированию логики отрисовки? Если иметь в виду, что каждый примитив имеет собственную отрисовку, и валить все в кучу не особенно хочется.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Какие в таком случае будут предложения по проектированию логики отрисовки? Если иметь в виду, что каждый примитив имеет собственную отрисовку, и валить все в кучу не особенно хочется.
При чем тут в кучу? Каждый примитив дает на выходе xsl:fo, путем комбинации выходов всех элементов получаем результирующий xsl:fo, его и отрисовываем. Где здесь куча?
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Воронков Василий, Вы писали:
ВВ>>Какие в таком случае будут предложения по проектированию логики отрисовки? Если иметь в виду, что каждый примитив имеет собственную отрисовку, и валить все в кучу не особенно хочется.
AVK>При чем тут в кучу? Каждый примитив дает на выходе xsl:fo, путем комбинации выходов всех элементов получаем результирующий xsl:fo, его и отрисовываем. Где здесь куча?
ОК. Тогда можно по-подробнее. Особенно интересует момент "примитив дает на выходе xsl:fo". Как это будет представлено?
Здравствуйте, Воронков Василий, Вы писали:
ВВ>ОК. Тогда можно по-подробнее. Особенно интересует момент "примитив дает на выходе xsl:fo". Как это будет представлено?
Ну примерно так:
Пусть собственно формирование на основе шаблонов данных уже завершено и на выходе имеет некий xml, описывающий результирующий отчет в терминах примитивов:
Теперь стоит задача отрисовать это. Набор тегов, которые содержаться в готовом отчете определяются подключенными плагинами. Т.е. каждый плагин публикует классы, каждому из которых соответствует некий тег во входном файле.
Входной файл парсится (или это уже готовый XmlDOM, полученный после xslt-преобразования шаблона) и каждому получившемуся куску находится ответственный за его отрисовку класс. Далее все поддерево с набором данных для отрисовки (и возможно какая то информация о стилях) передается этому классу. Класс на основании этих данных генерирует xsl:fo, собственно уже являющийся фактически набором команд рендереру отчета.
А ну все. До меня дошло наконец. Просто я не думал, что архитектура м.б. расширяемой именно в таком ключе. Однако один момент все же неясен.
Итак, распарсивается xml, обнаруживается скажем элемент image, далее ищется класс, ответственный за его отрисовку, если не находится, то данный элемент просто пропускается. — Тут все понятно. Непонятно другое — каким образом будет формироваться данный xml?Можно ли будет к уже 100% готовому репортеру прикрутить некий плагин, позволяющий отрисовывать те же гистограммы к примеру или же список элемент xml будет строго задан? А если не будет, как он будет формироваться? А если будет строго задан, то по большому счету зачем нужны плагины?
Здравствуйте, Воронков Василий, Вы писали:
ВВ> Непонятно другое — каким образом будет формироваться данный xml?
Путем наложения на входные данные xslt-преобразования ака шаблона отчета.
ВВ>Можно ли будет к уже 100% готовому репортеру прикрутить некий плагин, позволяющий отрисовывать те же гистограммы к примеру или же список элемент xml будет строго задан?
Список элементов xml и его структура полностью определяются составом наличествующих плагинов.
ВВ>А если не будет, как он будет формироваться?
Hello, "Ved" > > AVK>>>2) Прикрутить апачевский FOP, но он написан на джаве > Ved>>Сомнительная выгода. > AVK>Ну как сказать — зато бесплатный и регулярно обновляемый. > Да, это конечно большой плюс, вот только насколько быстрым получится взаимодействие .NET с Java?
А зачем именно Java? Многие проекты можно портировать просто используя J#
Posted via RSDN NNTP Server 1.6
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
12.08.03 11:13: Вся тема перенесена в специально созданный форум 'Генератор отчетов' — http://www.rsdn.ru/forum/?group=reports, в дереве — Проекты — Генератор отчетов — Форум
з.ы. Не забудьте сделать страничку с описанием проекта.
Здравствуйте, Ved, Вы писали:
Ved>Может, я не совсем понимаю, но цепь событий получается такая: Ved>
Ved>1) Юзер хочет просмотреть отчет перед печатью.
Ved> а) запрашивается шаблон
Ved> б) заполняем шаблон данными
Ved> в) преобразования до xsl:fo
Ved> г) Юзер ждет окна с внешним видом отчета. Кто его покажет? .NET или Java-вский конвертер?
Ved>2) Юзер отправляет на печать
Ved> а) ....
Ved> б) ....
Ved> в) ....
Ved> г) Кто печатает отчет вместе со всеми настройками?
Ved>
Вот такая вот штука уже есть много лет. TeX называется
Здравствуйте, Schade, Вы писали:
S>Adobe does not support or license development using the Acrobat ActiveX (OCX) S>component that ships with Acrobat and Acrobat Reader. Its purpose is to integrate S>with Internet Explorer. Adobe has no documentation available regarding ActiveX S>(OCX) development with Acrobat.
S>Использование ридера для отображения pdf в своем приложении запрещено лицензионными соглашением. Увы.
Увы, "Adobe does not support or license development" означает, что "валяйте на свой страх и риск, мы ничего не обещаем".
p.s. Как это, интересно, "кто-то" запретит мне создавать на своей машине COM-объекты?
Здравствуйте, Dimentiy, Вы писали:
D>Здравствуйте, Schade, Вы писали:
S>>Adobe does not support or license development using the Acrobat ActiveX (OCX) S>>component that ships with Acrobat and Acrobat Reader. Its purpose is to integrate S>>with Internet Explorer. Adobe has no documentation available regarding ActiveX S>>(OCX) development with Acrobat.
S>>Использование ридера для отображения pdf в своем приложении запрещено лицензионными соглашением. Увы.
D>Увы, "Adobe does not support or license development" означает, что "валяйте на свой страх и риск, мы ничего не обещаем".
D>p.s. Как это, интересно, "кто-то" запретит мне создавать на своей машине COM-объекты?
Имеется в виду запрет на использование _их_ ком-сервера, создание для интеграции с ИЕ, а не запрет на создание альтернативного ридера разумеется.
Заранее прошу прощения у присутствующих энтузиастов за этот свой постинг
AVK>Путем наложения на входные данные xslt-преобразования ака шаблона отчета.
xslt суть язык программирования, и по мне "шаблоном" быть не может никак.
xslt нужен для обработки файлов сложной структуры. Оглавления и подоглавления создавать, списки картинок, тезаурусы всякие, и т.д. Генератор отчётов — штука существенно более типовая.
Как Вы собираетесь "визуализировать" xslt-трансформатор? Он не визуализируется в принципе (как не визуализируется например текст на C++). Если не визуализировать, как делать генератор отчётов? Если делать "урезанный" генератор отчётов, зачем xslt?
Производительность — никакая. У меня DocBook книжка с помощью xslt собирается в html заметно больше минуты, особых наворотов там нет, компьютер не дохлый. Оно клиенту надо, иметь такой задумчивый Print Preview?
Причём при этом памяти оно кушает немерено (как и положено по технологии), да ещё просмотровщик результата, да ещё...
Да кстати, о DocBook-е в тему. Поскольку xslt создавался теоретиками, то имеем то что имеем. Де-факто книгу написанную в DocBook xslt-ируют в TeX (!!!), там доводят до ума оформление и уже оттуда печатают в pdf. А докбук — это не самый кислый DTD.
XML создан для обмена голыми данными, для отчёта же оформление нужно. Задумайтесь, почему именно Word установлен на столе у каждой секретарши?
В общем, оверхед это всё, и ничего кроме оверхеда. Странный теоретический изыск. IMHO.
Уж лучше тогда TeX использовать — он и компиляется быстрее, и выход красивее можно сделать.
--
p.s. Вы меня извините, что лезу в чужой огород — я в этот форум в первый раз попал — но что-то сомнения меня берут насчёт обоснованности применения xslt в генераторе отчётов.
А если уж человеку нужны навороты и человек понимает xslt — так он и xml для него сам сгенерирует не напрягаясь.
p.p.s. Если уж на то пошло, я бы html+css2 использовал как выходной стандарт — возможностей для генератора _отчётов_ — за глаза, имхо. Да и просмотровщик встроенный уже в памяти висит
Здравствуйте, Воронков Василий, Вы писали:
D>>p.s. Как это, интересно, "кто-то" запретит мне создавать на своей машине COM-объекты?
ВВ>Имеется в виду запрет на использование _их_ ком-сервера, создание для интеграции с ИЕ, а не запрет на создание альтернативного ридера разумеется.
Я естественно про создание экземпляра их объекта, ну да ладно, пофиг.
Мысль в том, что если на машине установлен Acrobat Reader, то появляется возможность использовать контрол — и эта возможность не исчезает, что бы там адоби не писали в своей бумажке.
p.s. Кстати в данном конкретном случае как раз с альтернативным ридером могут быть проблемы, бо pdf — закрытый патентованный формат (ИМХО).
Здравствуйте, Dimentiy, Вы писали:
D>xslt суть язык программирования, и по мне "шаблоном" быть не может никак.
Может ты не в курсе, но большинство приличных генераторов отчетов включают в шаблоны скриптовый язык. Так что все в порядке
D>xslt нужен для обработки файлов сложной структуры.
А преобразование входных данных в отчет это и есть "обработка файлов сложной структуры".
D>Оглавления и подоглавления создавать, списки картинок, тезаурусы всякие, и т.д.
Не надо только выдумывать того чего нет. Xslt предназначен для преобразования xml в текстовый фай, html или xml, точка. Все остальное от лукавого.
D>Как Вы собираетесь "визуализировать" xslt-трансформатор?
Как нибудь собираемся. Можешь поглядеть к примеру XML Spy stylesheet designer для преобразования в html.
D>Он не визуализируется в принципе
Визуализируется еще как
D>Производительность — никакая. У меня DocBook книжка с помощью xslt собирается в html заметно больше минуты,
Какой объем книги, какой размер xslt, какой парсер?
D> особых наворотов там нет, компьютер не дохлый. Оно клиенту надо, иметь такой задумчивый Print Preview?
А ты думаешь генераторы отчетов отчет размером с книжку мгновенно выводят?
D>Да кстати, о DocBook-е в тему. Поскольку xslt создавался теоретиками,
Кто тебе такую ерунду сказал? XSLT создавался как раз практиками.
D>XML создан для обмена голыми данными,
Опять сочиняешь.
D>для отчёта же оформление нужно.
Почитай про XSL:FO.
D>Задумайтесь, почему именно Word установлен на столе у каждой секретарши?
Действительно, почему не StarOffice? А вобще задумайся почему МС обещает что формат офисных файлов будет единым и он будет xml. Excel уже.
D>Уж лучше тогда TeX использовать — он и компиляется быстрее, и выход красивее можно сделать.
Можно и TeX для вывода, если ты напишешь его вьювер.
D>p.s. Вы меня извините, что лезу в чужой огород — я в этот форум в первый раз попал — но что-то сомнения меня берут насчёт обоснованности применения xslt в генераторе отчётов.
Чувствуется что ты достаточно поверхностно представляешь себе что такое xslt.
D>А если уж человеку нужны навороты и человек понимает xslt — так он и xml для него сам сгенерирует не напрягаясь.
В общем то да. Но рутины будет много. Вот эту рутину и нужно вынести в генератор.
D>p.p.s. Если уж на то пошло, я бы html+css2 использовал как выходной стандарт — возможностей для генератора _отчётов_ — за глаза, имхо.
Здравствуйте, Dimentiy, Вы писали:
D>Мысль в том, что если на машине установлен Acrobat Reader, то появляется возможность использовать контрол — и эта возможность не исчезает, что бы там адоби не писали в своей бумажке.
То есть ты предлагаешь не соблюдать условия лицензии? Это преступление к твоему сведению.
D>p.s. Кстати в данном конкретном случае как раз с альтернативным ридером могут быть проблемы, бо pdf — закрытый патентованный формат (ИМХО).
Конвертилки в пдф делались, делаются и будут делаться — причем на вполне законных основаниях. Есть куча прог не имеющих никакого отношения к адобе — в том числе и коммерческих — которые могут смотреть/создавать пдф. Не говоря уж об опенсурсах.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>То есть ты предлагаешь не соблюдать условия лицензии? Это преступление к твоему сведению.
Читать умеете? Я предлагаю более корректный с моей точки зрения перевод статьи:
> Увы, "Adobe does not support or license development" означает, что "валяйте на свой страх и риск, мы ничего не обещаем".
Также я утверждаю, что Adobe с полным правом может запретить распространение контрола со сторонним приложением — тут они в своём праве — но если я легально установил Acrobat Reader на свою машину, вызвать CreateCOMObject мне никто запретить не может, ни по каким законам.
Другой вопрос в том, разумно ли закладываться на такой "ненадёжный" контрол при разработке.
> Конвертилки в пдф делались, делаются и будут делаться ...
Спору нет, равно как и вьюеры (для unix например). Другое дело, насколько альтернативные решения поддерживают возможности формата — о чём и была речь. Хотя вполне допускаю, что в Adobe и можно получить на каких-то условиях спецификацию формата pdf.
Здравствуйте, Dimentiy, Вы писали:
ВВ>>То есть ты предлагаешь не соблюдать условия лицензии? Это преступление к твоему сведению. D>Читать умеете? Я предлагаю более корректный с моей точки зрения перевод статьи: >> Увы, "Adobe does not support or license development" означает, что "валяйте на свой страх и риск, мы ничего не обещаем".
Adobe does not support or license development using the Acrobat ActiveX (OCX) — я понимаю это так, что лицензия на бесплатный акробат не включает лицензию на использованию данного КОМа в девелопменте. А соответственно, использование будет нарушением лицензии.
D>Также я утверждаю, что Adobe с полным правом может запретить распространение контрола со сторонним приложением — тут они в своём праве — но если я легально установил Acrobat Reader на свою машину, вызвать CreateCOMObject мне никто запретить не может, ни по каким законам.
Вообще это и есть использование в девелопменте, которое они не лицензируют. И ничего здесь странного я не вижу.
D>Другой вопрос в том, разумно ли закладываться на такой "ненадёжный" контрол при разработке.
Если так, то к чему тогда весь этот базар про лицензии? Не говоря уж том, что от КОМа под дотнетом можно с каких угодно сторон ожидать каких угодно глюков.
>> Конвертилки в пдф делались, делаются и будут делаться ... D>Спору нет, равно как и вьюеры (для unix например). Другое дело, насколько альтернативные решения поддерживают возможности формата — о чём и была речь. Хотя вполне допускаю, что в Adobe и можно получить на каких-то условиях спецификацию формата pdf.
А всех возможностей формата и не надо. Речь идет просто об экспорте отчета в пдф.
Здравствуйте, AndrewVK, Вы писали:
AVK>Может ты не в курсе, но большинство приличных генераторов отчетов включают в шаблоны скриптовый язык. Так что все в порядке
Языки разные бывают.
D>>Оглавления и подоглавления создавать, списки картинок, тезаурусы всякие, и т.д. AVK>Не надо только выдумывать того чего нет. Xslt предназначен для преобразования xml в текстовый фай, html или xml, точка. Все остальное от лукавого.
Угу. Автомобиль предназначен для того, чтобы крутить колёсами. Чистая правда кстати
D>>Он не визуализируется в принципе AVK>Визуализируется еще как
Ну если условия if — then стали визуализироваться... тады ой.
/*-------------------------------------------------*
* Про визуализацию - подробнее след. постинг *
*-------------------------------------------------*/
D>> особых наворотов там нет, компьютер не дохлый. Оно клиенту надо, иметь такой задумчивый Print Preview? AVK>А ты думаешь генераторы отчетов отчет размером с книжку мгновенно выводят?
Здесь согласен, накосячил.
AVK>Кто тебе такую ерунду сказал? XSLT создавался как раз практиками.
Сам догадался
D>>XML создан для обмена голыми данными, AVK>Опять сочиняешь.
Не сочиняю. XML — формат обмена структурированными данными.
D>>Уж лучше тогда TeX использовать — он и компиляется быстрее, и выход красивее можно сделать. AVK>Можно и TeX для вывода, если ты напишешь его вьювер.
А что, нет вьюеров dvi? Я-то думал, они в комплекте идут
AVK>Чувствуется что ты достаточно поверхностно представляешь себе что такое xslt.
Чувствуется, что ты достаточно поверхностно представляешь себе перспективы вашего генератора отчётов.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Adobe does not support or license development using the Acrobat ActiveX (OCX) — я понимаю это так, что лицензия на бесплатный акробат не включает лицензию на использованию данного КОМа в девелопменте. А соответственно, использование будет нарушением лицензии.
Вот ведь упрямый
Смотри: http://www.intrinsyc.com/support/j-integra/doc/ocx/Acrobat_OCX.html
D>>Также я утверждаю, что Adobe с полным правом может запретить распространение контрола со сторонним приложением — тут они в своём праве — но если я легально установил Acrobat Reader на свою машину, вызвать CreateCOMObject мне никто запретить не может, ни по каким законам.
ВВ>Вообще это и есть использование в девелопменте, которое они не лицензируют.
Ежели бы они его _лицензировали_, им бы его суппортить приходилось. А так — можно пользовать, но если они все интефейсы поменяют (хотя не поменяют) — получается сам себе злобный буратино.
Повторяю ещё раз — никто не запретит вызывать функции операционной системы, и функции подсистемы COM не являются исключением из правила.
<OFF>Насчёт распространения. Сейчас прочитал на adobe насчёт распространения. Можно распространять Acrobat Reader с собственным программным обеспечением, с ограничениями. По случаю, одно из ограничений — если Ваш продукт генерирует pdf, распространять Adobe Reader нельзя. То есть на один компакт закатать Reader нельзя
Однако, если у пользователя есть Adobe Reader — использовать его всё равно никто не запретит.</OFF>
D>>Другой вопрос в том, разумно ли закладываться на такой "ненадёжный" контрол при разработке.
ВВ>Если так, то к чему тогда весь этот базар про лицензии?
Потому что перевод неправильный был, неужели до сих пор непонятно?
Глаз резануло. Исправил. Чё плохого-то?
Здравствуйте, Dimentiy, Вы писали:
AVK>>Может ты не в курсе, но большинство приличных генераторов отчетов включают в шаблоны скриптовый язык. Так что все в порядке
D>Языки разные бывают.
И что? К чему ты это сказал?
D>Угу. Автомобиль предназначен для того, чтобы крутить колёсами. Чистая правда кстати
Нет, для чего предназначен конкретный автомобиль ты можешь прочесть в его инструкции, в самом начале.
Вот что написано в инструкции по XSLT
A transformation expressed in XSLT describes rules for transforming a source tree into a result tree. The transformation is achieved by associating patterns with templates. A pattern is matched against elements in the source tree. A template is instantiated to create part of the result tree. The result tree is separate from the source tree. The structure of the result tree can be completely different from the structure of the source tree. In constructing the result tree, elements from the source tree can be filtered and reordered, and arbitrary structure can be added.
Где здесь написано что:
xslt суть язык программирования, и по мне "шаблоном" быть не может никак.
xslt нужен для обработки файлов сложной структуры. Оглавления и подоглавления создавать, списки картинок, тезаурусы всякие, и т.д.
D>Ну если условия if — then стали визуализироваться... тады ой.
А их и не надо визуализировать, как не визуализируются скрипты в обычных генераторах при дизайне. Визуализировать надо статическую часть.
AVK>>Кто тебе такую ерунду сказал? XSLT создавался как раз практиками.
D>Сам догадался
Ну а ты не гадай, а почитай в инете откуда взялся прообраз xslt.
D>>>XML создан для обмена голыми данными, AVK>>Опять сочиняешь.
D>Не сочиняю. XML — формат обмена структурированными данными.
Вот именно. А что это за данные это совсем другой вопрос.
AVK>>Можно и TeX для вывода, если ты напишешь его вьювер.
D>А что, нет вьюеров dvi? Я-то думал, они в комплекте идут
Здравствуйте, AndrewVK, Вы писали:
ВВ>>2) Насколько я понял у тебя шаблон отчета — это XML, в
AVK>XSLT
ВВ>> котором хранятся как данные, так и общие сведения о представлении.
AVK>Нет там никаких данных, только представление
ВВ>>(Где будут храниться детальные сведения о представлении? — цвет границ таблицы, шрифты и пр.
AVK>Вот именно там и будут
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, mrhru, Вы писали:
M>>В виде "кусочков" fo?
AVK>По желанию. Либо ввиде кусочков fo в самом шаблоне, либо ввиде xml во внешнем файле
Хорошо бы все этот как-то суммировать и включить в описание проекта.
Здравствуйте, Воронков Василий, Вы писали:
M>>>В виде "кусочков" fo?
AVK>>По желанию. Либо ввиде кусочков fo в самом шаблоне, либо ввиде xml во внешнем файле
ВВ>Хорошо бы все этот как-то суммировать и включить в описание проекта.
А уже можно где-нибудь посмотреть на драфт описания?
PS.
1. Посмотрел XEP 3.5 — хороший, но платный. Кроме того, авторы уже предлагают собственные расширения, не дожидаясь развития стандарта.
2. Апачевский fop — хороший и бесплатный. Правда, многие вещи из стандарта ещё не реализованы.
Есть встроенный вывод на экран (FOP AWT-Previewer). Скорее всего, в порте fop под .NET его можно будет использовать/поменять.
Здравствуйте, mrhru, Вы писали:
M>А уже можно где-нибудь посмотреть на драфт описания?
Технического описания пока нет, тк вопрос еще не полностью определен.
M>PS. M>1. Посмотрел XEP 3.5 — хороший, но платный. Кроме того, авторы уже предлагают собственные расширения, не дожидаясь развития стандарта.
M>2. Апачевский fop — хороший и бесплатный. Правда, многие вещи из стандарта ещё не реализованы. M>Есть встроенный вывод на экран (FOP AWT-Previewer). Скорее всего, в порте fop под .NET его можно будет использовать/поменять.
Да вообще много чего можно нарыть. Есть вот например опен-сурсный генератор здесь на джаве разумеется. По большому счету тот факт, что сабж будет основываться на чем-то вроде этого, тык сызыть самый определенный.
есть предложение написать свой генератор отчетов (типа RSDNReports ). Я бы например мог присоедениться к такому проекту (тоже не могу найти душевного генератора)
P>Замичатишно. Давай, присоединяйся. Как раз нужно сделать генератор. Существующий работает с Word'ом и, конечно, слабоват. Для начала постите сюда с SharpStudent'ом свои идеи.
Есть свой генератор отчетов, написаный на С++, с таблицами, рисунками, настройкой на любую базу данных (ODBC), страничная разбивка отчета и т.д. и т.п. писалось мной. Метоописания — XML.
Здравствуйте, <Аноним>, Вы писали:
А>Здравствуйте, Poudy, Вы писали:
P>>Здравствуйте, SiAVoL, Вы писали:
SAV>>>Вот в этом топике — Re[2]: Посоветуйте генератор отчетов
есть предложение написать свой генератор отчетов (типа RSDNReports ). Я бы например мог присоедениться к такому проекту (тоже не могу найти душевного генератора)
P>>Замичатишно. Давай, присоединяйся. Как раз нужно сделать генератор. Существующий работает с Word'ом и, конечно, слабоват. Для начала постите сюда с SharpStudent'ом свои идеи.
А>Есть свой генератор отчетов, написаный на С++, с таблицами, рисунками, настройкой на любую базу данных (ODBC), страничная разбивка отчета и т.д. и т.п. писалось мной. Метоописания — XML.
А>Что скажите?
Здравствуйте, Dimentiy, Вы писали:
AVK>>Под Win32? Не видел.
D>http://www.miktex.org
Интересный вариант. Не нашел лицензии. Если GNU то не получится использовать в не опенсурсном проекте. Будет время посмотрю насколько удобный и тормозной. Говорят что компиляция TeX процесс небыстрый.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Dimentiy, Вы писали:
AVK>>>Под Win32? Не видел.
D>>http://www.miktex.org
AVK>Интересный вариант. Не нашел лицензии. Если GNU то не получится использовать в не опенсурсном проекте. Будет время посмотрю насколько удобный и тормозной. Говорят что компиляция TeX процесс небыстрый.
Я было время использовал miktex.
ИМХО, просмотрщик очень неудобный. А время компиляции для современных компьютеров вроде вполне приемлимо. Хотя надо дополнительно проверить. Щас под рукой оказался только документик на 30 страниц, на P-IV 1.7, 512Mb, где-то 2-3 секунды.
Здравствуйте, AndrewVK, Вы писали:
D>>http://www.miktex.org
AVK>Интересный вариант. Не нашел лицензии.
miktex — это фактически сборник программного обеспечения, разные куски под разными лицензиями.
Соответственно, чтобы узнать что-то конкретное — надо смотреть этот модуль в их cvs-репозитории.
Здравствуйте, Poudy, Вы писали:
P>Здравствуйте, Воронков Василий, Вы писали:
ВВ>>Здравствуйте, AndrewVK, Вы писали:
AVK>>>Зачем??? Зачем сочинять свой собственный DOM, придумывать свою собственную механику заполнения этого шаблона данными? Что ты этим получишь кроме горы работы и нестандартности решения? P>Да все то же самое. Только custom может получиться быстрее — устаешь от чужик багов.
Вряд ли "custom может получиться быстрее", не боишься выдохнуться? Может лучше реализовать сначала с минимумом custom и ближе к стандартам, а то ведь все расползется. Имхо наилучшая стратегия с помощью небольших базовых звеньев соединить цепочку/скелет от задачи до результата. Имея действующий механизм подключаться люди, которые хотят именно пользовать систему, а не программить ее. Прокачивая данные через программу, будет понятно в каком направлении рефакторить.
Без сомнения, стоит выбирать сторонние модули наиболее стабильные, либо использовать в них стабильно работающую функциональность.
Здравствуйте !
Я тоже изучаю NET и мечтаю для опыта бесплатно поработать в реальном проекте. Мне очень понравилась идея создания такого проекта на форуме. Но честно говоря, простите моё невежество, я не совсем понимаю, чем вам не нравится Crystal Report. Но
вообще к проекту генератора отчетов или другому очень хочу присоединиться, но уже конец сентября... все заглохло ?
С уважением
Aniz
Здравствуйте, Aniz, Вы писали:
A>... я не совсем понимаю, чем вам не нравится Crystal Report...
Возможностями + большая стоимость более полной версии.
A>вообще к проекту генератора отчетов или другому очень хочу присоединиться, но уже конец сентября... все заглохло ?
Здравствуйте, Aniz, Вы писали:
A>Здравствуйте ! A>Я тоже изучаю NET и мечтаю для опыта бесплатно поработать в реальном проекте. Мне очень понравилась идея создания такого проекта на форуме. Но честно говоря, простите моё невежество, я не совсем понимаю, чем вам не нравится Crystal Report. Но
Цена + патриотизм
A>вообще к проекту генератора отчетов или другому очень хочу присоединиться, но уже конец сентября... все заглохло ? A>С уважением A>Aniz
Вот как главный дядя из отпуска вернется так сразу и начнем.
Здравствуйте, wara, Вы писали:
W>Какие новости о ходе проекта? Заглох?
У проекта есть отдельный форум, но там уже давно никто не пишет. Проект умер так и не родившись. Причина — отсутствие руководителя. Желающих писать было много, а руководить и принимать решения никто не взялся.
Здравствуйте, SiAVoL, Вы писали:
SAV>Проект умер так и не родившись. Причина — отсутствие руководителя. Желающих писать было много, а руководить и принимать решения никто не взялся.
А жаль, нужное начинание. Я бы сам поруководил , но именно в C# пока опыта маловато.
Здравствуйте, avg_sng, Вы писали:
SAV>>Проект умер так и не родившись. Причина — отсутствие руководителя. Желающих писать было много, а руководить и принимать решения никто не взялся.
_>А жаль, нужное начинание. Я бы сам поруководил :) , но именно в C# пока опыта маловато.
А чем MSSQL Server Reporting Services не нравится?
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, TK, Вы писали:
TK>А чем MSSQL Server Reporting Services не нравится?
Нравится. Но как всегда есть но. Как я писал в более ранних постах, RS достаточно монстрообразен — это своего рода портал отчетов для крупного предприятия — здесь все ОК. Но как быть с рабочим местом на удаленном складе, не имеющем постоянного коннекта с центральным сервером? Или там тоже подымать IIS и т.д.? Я предлагал использовать RDL для унификации с MS-овским RS, но для использования в Windows.Forms при создании десктопных приложений. Тем более, что на первых порах можно было бы использовать дизайнер отчетов от RS, а написать только компонент для рендеринга и печати по готовому шаблону. Ну и предусмотреть там всякие дополнительные фичи типа хранения шаблона отчета в самой БД и т.п. Использование RDL добавляет еще один плюс — постановка задачи не требуется — она уже поставлена (почти ).
Здравствуйте, avg_sng, Вы писали:
_>Здравствуйте, TK, Вы писали:
TK>>А чем MSSQL Server Reporting Services не нравится?
_>Нравится. Но как всегда есть но. Как я писал в более ранних постах, RS достаточно монстрообразен — это своего рода портал отчетов для крупного предприятия — здесь все ОК. Но как быть с рабочим местом на удаленном складе, не имеющем постоянного коннекта с центральным сервером? Или там тоже подымать IIS и т.д.? Я предлагал использовать RDL для унификации с MS-овским RS, но для использования в Windows.Forms при создании десктопных приложений. Тем более, что на первых порах можно было бы использовать дизайнер отчетов от RS, а написать только компонент для рендеринга и печати по готовому шаблону. Ну и предусмотреть там всякие дополнительные фичи типа хранения шаблона отчета в самой БД и т.п. Использование RDL добавляет еще один плюс — постановка задачи не требуется — она уже поставлена (почти ).
так что, получается нужно только растеризатор реализовать?
все остальное брать MS-стандартное?
Здравствуйте, vdimas, Вы писали:
V>так что, получается нужно только растеризатор реализовать? V>все остальное брать MS-стандартное?
Я же сказал — почти
Объектная модель описана в RDL (ее и надо реализовать). На первых порах использовать дизайнер от MS. Фильтры экспорта тоже опускаем на потом. Действительно остается рендеринг (превью и печать). Если дело пойдет — можно будет занятся и дизайнером.
Здравствуйте, avg_sng, Вы писали:
_>Здравствуйте, vdimas, Вы писали:
V>>так что, получается нужно только растеризатор реализовать? V>>все остальное брать MS-стандартное?
_>Я же сказал — почти
_>Объектная модель описана в RDL (ее и надо реализовать). На первых порах использовать дизайнер от MS. Фильтры экспорта тоже опускаем на потом. Действительно остается рендеринг (превью и печать). Если дело пойдет — можно будет занятся и дизайнером.
превью и печать — это самое плевое дело и к рендерингу не относится.
нужен движок, который формирует layout, итоги и пр. и пр.
выходом движка должна быть объектная модель ИНСТАНСОВ элементов репорта.
(во время рендеринга одно поле репорта может породить множество своих инстансов)
по этим инстансам уже можно что-то рисовать или экспортить в какой-нить формат.
Здравствуйте, vdimas, Вы писали:
V>превью и печать — это самое плевое дело и к рендерингу не относится.
V>нужен движок, который формирует layout, итоги и пр. и пр. V>выходом движка должна быть объектная модель ИНСТАНСОВ элементов репорта. V>(во время рендеринга одно поле репорта может породить множество своих инстансов) V>по этим инстансам уже можно что-то рисовать или экспортить в какой-нить формат.
V>дай самую хорошую ссылку на описание этого RDL
А кто говорил что превью и печать это самое сложное . Я говорил о рендеринге в полном объеме, а превью и печать — это выход на твердую (бумажную) копию, которая как показывает практика (моя) требуется в первую очередь, причем немаловажны качество и скорость вывода этих копий. Так что это не совсем так уж и просто.
Да и с остальным я почти согласен. Мало того — уже в какой-то мере реализовано, правда под COM, а хочется под NET, да под стандарт, хотя-бы RDL.
есть предложение написать свой генератор отчетов (типа RSDNReports ). Я бы например мог присоедениться к такому проекту (тоже не могу найти душевного генератора)
P>Замичатишно. Давай, присоединяйся. Как раз нужно сделать генератор. Существующий работает с Word'ом и, конечно, слабоват. Для начала постите сюда с SharpStudent'ом свои идеи.
Поучаствую в проекте изобретения велосипеда!!! СРОЧНО!
). Я бы например мог присоедениться к такому проекту (тоже не могу найти душевного генератора)
).
, фиксить попроще (не надо в чужом коде разбираться). Проблема — человеко-месяцы. Вопрос — сколько ориентировочно на это может уйти? (Спрашиваю потому, что с xsl:fo не работал, но интересно) Если до человеко-года-полутора при возможности писать втроем-четвером — то это терпимо.
Первый раз такое слышу
:только в coomonly used случаях, если пользовать "нестандартно" или, что чаще, пользовать на полную катушку, то, даже не выходя за рамки reference, можно накопать червей.
