T>Вот это будет проект века! и все с префиксом RSDN. Это может хорошо распрострониться.
Постойте, постойте. Распостранится среди просто пользователей или клиентов ? Не моймите меня не правильно, но во всей цепочке "успеха" это пока что белое пятно.
Здравствуйте, Tiger, Вы писали:
T>Но почему же просто генератор отчетов. Итак T>1) Генератор отчетов. T>2) Грид (стоит посмореть на стенания в форумах поповоду гридов T>3) Комбо T>4) Текст бокс T>5) много чего еще (например ветка всяких бизнес компонентов, графических библиотек в рамках одной архитектуры)
T>Объединить это в Kit (Вариант — RSDN Controls Kit)
T>Вот это будет проект века! и все с префиксом RSDN. Это может хорошо распрострониться. T>Блин ну почему нельзя частей на пять разорваться
Здравствуйте, SharpStudent, Вы писали:
SS>Самому что-то абсолютно ничего на ум не приходит. Может подкинешь идею? Умения думаю хватит SS>Я считаю, что гораздо легче писать что-то новое(пусть не приложение, пусть просто какую-то часть, классы), чем копаться в куче чужого кода и фиксить чужие баги.
Здравствуйте, SharpStudent, Вы писали:
T>>Но почему же просто генератор отчетов. Итак SS>... T>>3) Комбо T>>4) Текст бокс SS>...
SS> А чем тебя не устраивают стандартные комбо и текст бокс?
Тем что когда я подключаю стандартные контролы у них в названии отсутствует префикс RSDN
Помните как там в байке про майкрософт — "Однажды группа програмистов в МS решила что DEE плох потому что это писали не они"
Нет если серьезно — был бы неплох набор контролов (например со стандартными свойствами привязка к БД). Образец например ascLib. Влад сделал классную вещь — стоит и посмотреть и попробывать. Хотя нет префиса RSDN —
Ну вот — а реализовать это гамотно, в единой архитектуре да еще и на .NET — это ИМХО стоящее!
Итак, может давайте не будем ссориться и подведем итоги этих все споров?
Вот пока что предварительные требования к отчетам, как на мой взгляд:
1) Расчет на обычного рядового пользователя.
2) Скорость работы и по возможности меньшая ресурсоемкость.
3) Возможность просмотра отчета без печати — отчеты в бОльшем количестве случаев не печатаются, а просматриваются.
4) Расширяемость и возможность добавления как плагинов новых объектов в отчеты.
5) Наличие дизайнера отчетов — часто проще и удобнее воспользоваться дизайнером, чем писать от руки. Кроме того, если писать не для своего использования, а и с расчетом на более или менее коммерческое использование.
6) Возможность экспорта в большее по возможности количество форматов.
Может лучше сперва обсудить все требования (если, конечно этим заняться, а не спорить и соориться попусту), а потом уже методы реализации.
Здравствуйте, Ved, Вы писали:
Ved>Здравствуйте, All, Вы писали:
Ved>Итак, может давайте не будем ссориться и подведем итоги этих все споров? Ved>Вот пока что предварительные требования к отчетам, как на мой взгляд:
Ved>1) Расчет на обычного рядового пользователя. Ved>2) Скорость работы и по возможности меньшая ресурсоемкость. Ved>3) Возможность просмотра отчета без печати — отчеты в бОльшем количестве случаев не печатаются, а просматриваются. Ved>4) Расширяемость и возможность добавления как плагинов новых объектов в отчеты. Ved>5) Наличие дизайнера отчетов — часто проще и удобнее воспользоваться дизайнером, чем писать от руки. Кроме того, если писать не для своего использования, а и с расчетом на более или менее коммерческое использование. Ved>6) Возможность экспорта в большее по возможности количество форматов.
Я бы еще добавил Возможность динамического генерирования отчетов и шаблонов.
Здравствуйте, SiAVoL, Вы писали:
SAV>Я бы еще добавил Возможность динамического генерирования отчетов и шаблонов.
Дело. Причем можно весь проект разбить на основную и дополнительную функциональность. Всю основную реализовывать в движке, а дополнительную — в плагинах. Это позволит ускорить и упростить разработку.
Здравствуйте, Ved, Вы писали:
Ved>Здравствуйте, All, Вы писали:
Ved>Итак, может давайте не будем ссориться и подведем итоги этих все споров? Ved>Вот пока что предварительные требования к отчетам, как на мой взгляд:
Ved>1) Расчет на обычного рядового пользователя.
Не совсем ясно. Но если ты имеешь в виду, что пользователь может иметь весьма низкую квалификацию, то тогда придется реализовываться всякие визуальные вкусности — а по большому счету потребуется фул дизайн-тайм суппорт, что конечно кульно, но весьма геморойно.
Ved>2) Скорость работы и по возможности меньшая ресурсоемкость.
Ved>3) Возможность просмотра отчета без печати — отчеты в бОльшем количестве случаев не печатаются, а просматриваются.
+1. Но работы здесь — море.
Ved>4) Расширяемость и возможность добавления как плагинов новых объектов в отчеты.
+1
Ved>5) Наличие дизайнера отчетов — часто проще и удобнее воспользоваться дизайнером, чем писать от руки. Кроме того, если писать не для Ved> своего использования, а и с расчетом на более или менее коммерческое использование.
+1 именно при указанном тобой "если". Но этим нужно будет заняться уже в конце.
Ved>6) Возможность экспорта в большее по возможности количество форматов.
Ну это понятно. +1
Ved>Может лучше сперва обсудить все требования (если, конечно этим заняться, а не спорить и соориться попусту), а потом уже методы реализации.
Здравствуйте, SiAVoL, Вы писали:
SAV>Здравствуйте, Ved, Вы писали:
Ved>>Здравствуйте, All, Вы писали:
Ved>>Итак, может давайте не будем ссориться и подведем итоги этих все споров? Ved>>Вот пока что предварительные требования к отчетам, как на мой взгляд:
Ved>>1) Расчет на обычного рядового пользователя. Ved>>2) Скорость работы и по возможности меньшая ресурсоемкость. Ved>>3) Возможность просмотра отчета без печати — отчеты в бОльшем количестве случаев не печатаются, а просматриваются. Ved>>4) Расширяемость и возможность добавления как плагинов новых объектов в отчеты. Ved>>5) Наличие дизайнера отчетов — часто проще и удобнее воспользоваться дизайнером, чем писать от руки. Кроме того, если писать не для своего использования, а и с расчетом на более или менее коммерческое использование. Ved>>6) Возможность экспорта в большее по возможности количество форматов.
SAV>Я бы еще добавил Возможность динамического генерирования отчетов и шаблонов.
Здравствуйте, Ved, Вы писали:
SAV>>Я бы еще добавил Возможность динамического генерирования отчетов и шаблонов. Ved>Дело. Причем можно весь проект разбить на основную и дополнительную функциональность. Всю основную реализовывать в движке, а дополнительную — в плагинах.
Да вобщем для дотнета особого смысла что то встраивать стандартное нет, разницы между статической и динамической линковкой нет никакой.
Здравствуйте, Ved, Вы писали:
Ved>1) Расчет на обычного рядового пользователя.
Как то расплывчато и по большому счету непонятно о чем.
Ved>2) Скорость работы и по возможности меньшая ресурсоемкость.
Опять же без конкретных цифр ни к чему не обязывает. Какая скорость? Какая ресурсоемкость? Насколько этот фактор критичен по отношению к другим?
Ved>3) Возможность просмотра отчета без печати — отчеты в бОльшем количестве случаев не печатаются, а просматриваются.
Ну это понятно.
Ved>4) Расширяемость и возможность добавления как плагинов новых объектов в отчеты.
Согласен
Ved>5) Наличие дизайнера отчетов — часто проще и удобнее воспользоваться дизайнером, чем писать от руки. Кроме того, если писать не для своего использования, а и с расчетом на более или менее коммерческое использование.
Не уверен что это первоочередная задача. Для начала нужен движок, а уж потом можно прикрутить и дизайнер. Решения, не позволяющие обходиться без дизайнера мне не очень нравяться. К примеру для больших проектов большую часть шаблонов документации скорее всего можно будет сделать автоматически. Так что документированность формата шаблонов это большой плюс.
Ved>6) Возможность экспорта в большее по возможности количество форматов.
Согласен. Минимум — pdf, rtf, doc, html.
Ved>Может лучше сперва обсудить все требования (если, конечно этим заняться, а не спорить и соориться попусту), а потом уже методы реализации.
Я не понял — а что, решение о начале проекта уже принято?
Здравствуйте, AndrewVK, Вы писали:
AVK>Да вобщем для дотнета особого смысла что то встраивать стандартное нет, разницы между статической и динамической линковкой нет никакой.
Только встраиваемое надо сразу писать, а динмическое — можно и потом
Здравствуйте, Воронков Василий, Вы писали:
SAV>>Я бы еще добавил Возможность динамического генерирования отчетов и шаблонов.
ВВ>А что это?
Возможность построения отчета динамически, из кода на "автопилоте", а не дизайнером
Здравствуйте, Воронков Василий, Вы писали:
Ved>>1) Расчет на обычного рядового пользователя. ВВ>Не совсем ясно. Но если ты имеешь в виду, что пользователь может иметь весьма низкую квалификацию, то тогда придется реализовываться всякие визуальные вкусности — а по большому счету потребуется фул дизайн-тайм суппорт, что конечно кульно, но весьма геморойно.
Но без этого — еще хуже. Тем более что отсутствие дизайнера ведет к излишнему напрягу юзера, и что в конечном итоге отпугнет очень многих. Кроме того, надо учесть возможность использования не-программерами. Например, один человек продукт пишет, а другой — к несу отчеты ваяет. Конечно, научить кого угодно можно, вот только сколько на это времени уйдет? Отсутствие дизайнера отпугнет очень многих, если же убрать и предварительный просмотр — то понадобится это единицам. И зачем это тогда надо?
Ved>>2) Скорость работы и по возможности меньшая ресурсоемкость. ВВ>
Сервер отчетов (кстати, в требованиях я его не упомянул, полагая само собой разумеющимся) обязан быть быстрым — в некоторые периоды (например, отчетный период в бухгалтерии, конец года и т.п.) на него может лечь достаточно высокая нагрузка. Мало ли как и кто его использовать будет?
Ved>>3) Возможность просмотра отчета без печати — отчеты в бОльшем количестве случаев не печатаются, а просматриваются. ВВ>+1. Но работы здесь — море.
Море. Но это необходимо. Я бы первым не купил бы продукт без этого — сфера генерации отчетов без просмотра достаточно узка.
Здравствуйте, Ved, Вы писали:
AVK>>Да вобщем для дотнета особого смысла что то встраивать стандартное нет, разницы между статической и динамической линковкой нет никакой. Ved>Только встраиваемое надо сразу писать, а динмическое — можно и потом
А вот это уже ошибка. Конфигурируемость надо закладывать изначально, иначе слишком борого потом обойдется ее добавление.
Здравствуйте, Ved, Вы писали:
Ved>Здравствуйте, Воронков Василий, Вы писали:
Ved>>>1) Расчет на обычного рядового пользователя. ВВ>>Не совсем ясно. Но если ты имеешь в виду, что пользователь может иметь весьма низкую квалификацию, то тогда придется реализовываться всякие визуальные вкусности — а по большому счету потребуется фул дизайн-тайм суппорт, что конечно кульно, но весьма геморойно. Ved>Но без этого — еще хуже. Тем более что отсутствие дизайнера ведет к излишнему напрягу юзера, и что в конечном итоге отпугнет очень многих. Кроме того, надо учесть возможность использования не-программерами. Например, один человек продукт пишет, а другой — к несу отчеты ваяет. Конечно, научить кого угодно можно, вот только сколько на это времени уйдет? Отсутствие дизайнера отпугнет очень многих, если же убрать и предварительный просмотр — то понадобится это единицам. И зачем это тогда надо?
Дизайнер конечно нужен, но мы же не будем сразу заниматься его реализацией. Так что по любому в число приоритетный задач на первый этап он не входит.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Дизайнер конечно нужен, но мы же не будем сразу заниматься его реализацией. Так что по любому в число приоритетный задач на первый этап он не входит.
Сразу — нет конечно. Сразу надо заниматься архитектурой, форматами и т.п. А потом уже постараться распарараллелить работу — сперва движок, а потом может лучше часть людей займется вьюером, часть — дизайнером. Это, конечно, если будет достаточно желающих. И получится быстрее, чем сперва вьюер, потом — дизайнер.
Здравствуйте, AndrewVK, Вы писали:
AVK>А вот это уже ошибка. Конфигурируемость надо закладывать изначально, иначе слишком борого потом обойдется ее добавление.
А я нигде и не говорил, что это надо потом — это и ежу понятно что такие вещи (конфигурируемость, плагины) закладывают изначально — в архитектуру.
? Не моймите меня не правильно, но во всей цепочке "успеха" это пока что белое пятно.
