Здравствуйте, Dimonka, Вы писали:
D>Доброго времени суток. D>Меня всё мучает идея создания некоего универсального движка для создания и управления формами (видами, экранами). D>Основная мысль — сделать что-то на подобие Дельфи:
D>* Редактор форм D>* Редактор компонент (Инспектор + визуальные прибамбасы) D>* Редактор скриптов D>* Связи скриптов и событий у компонент D>* Рантаймовая часть, которая всё это дело будет запускать в приложении.
D>Всё вроде не сложно. D>Все отдельные части как бы есть: TMS Scripter Studio, Greatis Runtime Fusion, DevExpress Subscription , но возникают следующие проблемы: D>- Сохранение форм / скриптов итд D>- Возможность гибкой локализаци (её отсутствие скорее) D>- Красивая связь событий и скриптов (Писать оболочки для всех компонент, которые будут отвечать за связь между событиями и реакции на них скриптов?) D>- Та же проблема с сохранением (делать на каждый компонент сохранялку/загружалку? или воспользоваться встроеной сериализацией)
D>Может есть уже что-то готовое?
Есть. Как частичные решения (комбинации из тобою перечисленных своств), так и готовые (грубо говоря демострационное повторение дельфи). К первым относится http:,www.fastreport.net(вместе с FastScript, а тем более в 3 версии все это слили в одно решение) и еще одну беду встречал ипа дизайнера, но адрес не помню. ко вторым попробуй найти ralib. там был пример интепретатора дельфи с редактором кода, отладчиком и пр.
Да и вообще много сейчас программ видел использующих эту технологию борланда (OLAP-менеджеры, настройки ресурсов различные).
на твои сомнения есть куча примеров, как это сделали другие.
— Сохранение форм / скриптов итд.
зачем изобретать велосипед. посмотри класс TStream, а особенно события ReadComponent, WriteComponent. Я и сам этим часто пользуюсь, что бы не липить прокладки из ини или регистра.
— Возможность гибкой локализаци (её отсутствие скорее)
ну это риторический вопрос — можно хоть дельфю локализовать. только нужно кому-то сесть и написать. кстати вроде мне друзья показывали такой эксперт на дельфю.
— Красивая связь событий и скриптов (Писать оболочки для всех компонент, которые будут отвечать за связь между событиями и реакции на них скриптов?)
смотри как сделано в ralib и FastScript. А можешь последний купить и пользоваться в свое усмотрение. А можешь с тори скачать "прообразы" и слепить так же то той же технологии.
— Та же проблема с сохранением (делать на каждый компонент сохранялку/загружалку? или воспользоваться встроеной сериализацией)
я думаю, уже был ответ на этот вопрос (выше). Хотя дельфи и сама может работать с любым хранилищем данных. для этого в IDE поддерживается интерфейс TVirtualFileSystem(FileIntf.pas). Правда это делалось для сопряжения дельфи с VCS, но можно и использовать в своих корыстных целях (например хранение модулей в базе данных или в инете).
Почему никто не делает нечто подобное? Все упирается в компилятор. Без него это все только "подделка под ...", а фактичекого применения иногда мало. Сейчас появились и другие компиляторы — FreePascal — и тут же пытливые программеры сразу же под него налепиля дельфи-интерфейс — Lazarus.
Так что если есть желание, делай. Но не забудь, что чаще пользоваться будешь только ты.
А если хочешь что-то полезное сделать , что бы пользовались все, то свою идею попробуй вложить в эксперт к дельфе. Для начала посмотри уже готовые эксперты, напрмер CodeRush или Atlant.
Hello, Dimonka!
You wrote on Wed, 04 Aug 2004 13:16:35 GMT:
D> Здравствуйте, eugals, Вы писали:
E>> "Бесплатных и с исходниками" я таких систем пока не видел (вернее видел E>> — Qt — но тебя ведь VCL интересует, насколько я понял?). А вообще, у E>> нас, например, вышел недавно (в мае) E>> первый релиз такого движка:
D> Что-то у вас там всё про кубы какие-то написано, да про BDE.. D> Про бесплатность — это я конечно загнул, но вот исходники точно нужны. D> Плюс очень нужна ориентация на внешний вид, т.е. на сторонние компоненты D> (DevExpress). Плюс в качестве скриптов желательно паскаль или си. Бейсик D> на крайняк
D> Сколько будет примерно стоить такой движок?
Hello, Dimonka!
D> Вот-вот, что-нибудь в этом роде, только с более простым интефейсом.
Дык я и говорю, что есть и много.
И это действительно оправдывает себя. Легче все стандартизовать и если нужно изменить все до неузнаваемости (пишем сверху вниз и слева направо иероглифами, формы со скинами и т.д.) — просто вносядся изменения в движок, а логика и сценарии использования остаются такими, как были написаны.
И трудоемкость создания приложений падает на порядок. Но имеет смысл только для крупных и динамичных проектов.
Если у тебя есть ресурсы — пиши под себя. Если нету — нет смысла покупать — проще использовать дельфи.
Hello, eugals!
You wrote on Wed, 04 Aug 2004 14:42:23 GMT:
e> Здравствуйте, eugals, пара картинок:
Это малость не то что у нас.
У нас тут настраивается мэппирование, генерируется структура БД и т.п.
У вас там скорее IDE для Python.
Кстати, объясните мне в чем прелесть питона. А то тут столкнулся — не особо понял всех радостей, окромя отсутствия операторных скобок, конечно
Здравствуйте, svd71, Вы писали:
D>>Может есть уже что-то готовое?
S>Есть. Как частичные решения (комбинации из тобою перечисленных своств), так и готовые (грубо говоря демострационное повторение дельфи). К первым относится http:,www.fastreport.net(вместе с FastScript, а тем более в 3 версии все это слили в одно решение) и еще одну беду встречал ипа дизайнера, но адрес не помню. ко вторым попробуй найти ralib. там был пример интепретатора дельфи с редактором кода, отладчиком и пр.
hmm..
ANN: RALib joins JVCL
August 2002:
JVCL 2.0 Beta released (incl. RALib, JvBands, and JEDI Installer).
Здравствуйте, Dimonka, Вы писали:
S>>И? Во-первых — не вижу разницы между отправкой 50Кб dll и 50Кб скрипта, за исключением того, что технология delphi+dll — кардинально более используемая и, соответственно, кардинально более надежная и гибкая. D>И чем решение со скриптами менее надёжное?
Компилятор, используемый десять лет в десятках тысяч инсталляций — надежнее того, что найдете Вы. Система, по которой полно литературы и готовых специалистов — надежнее в использовании, нежели похожая, но другая (в смысле — будет меньше ошибок из-за особенностей).
S>>Именно — посылаем измененную часть программы (dll). D>Я не понимаю разницы.. Версионировать можно и скрипты.. Причём не менее успешно, чем длл-ки.
Вопрос в том, что и не более успешно. Вы хотите сделать новую сложную в реализации технологию, которая загрузит Вас работой по поддержке — но не дает преимуществ перед имеющейся отработанной технологией при грамотном использовании последней.
S>>Я и говорю — если собираетесь посылать кучу народа с ноутбуками по заказчикам, начинает играть роль вопрос стоимости лицензий. Но если есть такая куча заказчиков, что нужно держать десятки подобных внедренцев.. D>Речь идёт не о конкретной системе, а так.. на переспективу..
Тем более. Начинать перспективную систему нужно с отработанного базиса. По крайней мере — если нет неограниченного кредита и вечной жизни (в смысле сроков).
D>Никто и не говорит о стаде внедренцев, а лишь об упрощении поддержки и расширения.
Упрощения пока что не видно. Удешевление — может быть такой аргумент, но без стада внедренцев он неактуален.
D>Что значит "нормальное"? Для того, чтобы переводчик приступил к работе, я ему должен послать не менее полусотни мегов бпл-ок.. Это по-моему не нормально.. А если переводчик понятия не имеет, что такое Дельфи? Его ж кандратий схватит от интуитивности интерфейса..
Во-первых, переводчик для нормальной работы должен видеть контекст — окно или что там будет. Можно, конечно, вырезать и послать ему просто набор строковых констант — и, полагаю, не особо сложно — но результат будет соответствующим.
S>>Что касается чудовищности.. мне кажется мерзким, когда в локализованной винде обрезается текст сообщения в каком-нибудь системном окне. Хотя они следят за этим неплохо, но иногда все же пропускают.. D>Есть и другие способы решать вопрос обрезания текста.
Да наздоровье Я не вижу никакой сложности в написании компонента, который рассует по местам указанный текст на указанном языке. Если он будет выполнять "другие способы" — вопрос только в сложности реализации этих способов. Скрипты для этого не нужны.
D>И опять мы возвращаемся к стоимости самого рабочего места, к стоимости поддержки этого рабочего места, ко времени обучения..
Так я и хочу показать, что это единственный аргумент. А чтобы он был решающим, нужна толпа внедренцев. А если есть толпа внедренцев — есть и куча успешных продаж, и соответствующие деньги.
D>"Ой а у меня компоненты куда-то все делись!" D>Я не понимаю, почему такое отторжение?
Хм. Трудно сказать, на самом деле Возможно, оттого, что почему-то тема "а как бы написать свою дельфу" почему-то довольно популярна среди малограмотных коллег и вызывает уже полуавтоматическую реакцию.
S>>Сколько у Вас таких студентов? Есть подозрение, что пара рабочих мест дельфы обойдется дешевле, нежели Ваше время на сборку и поддержку этого решения даже из готовых компонент. Не говоря уже о времени, в течение которого будет идти отработка технологии (надеюсь, Вы понимаете, что первые версии редко бывают финальными). D>Зато когда будет всё готово — тогда лепи и лепи себе приложения да апдейты к ним
Именно. А без этого можно лепить приложения уже прямо сейчас
Скажем так, если нет проекта уровня действительно 1C и Паруса, я усомнюсь в оправданности такого решения. Да и 1C, сколь помнится, обрела это решение не в первой версии. Как было написано в одной из статей на этом сайте — "небольшие фирмы должны создавать приложения, а не платформы".
Кстати, еще один момент — про студентов. Я в свое время отказался от довольно денежного предложения на Гупту. Потом — на ABAP. По одной простой причине: я не буду связываться с "боковой веткой", после которой я выйду искать следующую работу крупным знатоком никому не нужной хрени. И вменяемые "студенты", полагаю, будут думать так же.
Hello, Softwarer!
S> И вменяемые "студенты", полагаю, будут думать так же.
Одна ремарка: все зависит от специальности студента, ну или не студента. По поводу студентов тут перегиб. Не нужны студенты, а нужны специалисты в своих областях.
Программисты совершенствуют движок ситемы. Аналитик-экономист разрабатывает иерархию классов и их отношения, потом внедренец (тоже экономист/программист) реализует сценарии использования на уровне представления.
И усе... готово приложение. Экономисты развиваются в сторону логистики, бюджетирования, ISO и GAAP, а программисты в сторону VCL, CLX, .NET или чего-то там еще. Узкая специализация получается и все довольны, ошибок меньше, цикл разработки короче, динамичность выше, скорость обработки запросов на изменение просто-таки гигантская (прямо у клиента в тот же день и в тот же час).
Здравствуйте, svd71, Вы писали:
S>Не нашел такого в JVCL. в RALib был пример под название "RedOctovber"
1. RAI2 (interpreter) — as standalone subproject of JVCL called JVI2;
2. RAFD (form designer) — as standalone subproject of JVCL called JVFD;
3. All other (visual) components will be integrated directly into JVCL
library.
Здравствуйте, s.ts, Вы писали:
ST>Это малость не то что у нас. ST>У нас тут настраивается мэппирование, генерируется структура БД и т.п. ST>У вас там скорее IDE для Python.
Ну, настроуки мэппирования и связь с нашей структурой БД эта штука тоже поддерживает, в качестве плагина.
ST>Кстати, объясните мне в чем прелесть питона. А то тут столкнулся — не особо понял всех радостей, окромя отсутствия операторных скобок, конечно
Тут немного не тот форум, на котором это нужно обсуждать, поэтому буду краток:
Довольно подробный учебник (см. русский перевод) по языку написал сам его создатель — Гвидо Ван Россум.
Дополнительные материалы можно найти на Python.Ru и Python.Org.
Напишу главные достоинства Питона для меня (какие вспомню):
Чрезвычайная лаконичность (самый лаконичный из известных мне языков. и дело тут не только в операторных скобках)
Мощные средства метапрограммирования (метаклассы, интроспекция (рефлексия) etc.)
Всякие мелкие радости, типа встроенных итераторов/чисел неограниченной разрядности/строковых типов/множественного наследования и т.п.
Большая стандартная библиотека (парсер xml/транспорты pop+smtp+ftm+http/фреймворк для развертывания сторонних библиотек...)
Удобное Python/C API, для написания расширений на Cи.
...
Здравствуйте, Softwarer, Вы писали:
D>>Что значит "нормальное"? Для того, чтобы переводчик приступил к работе, я ему должен послать не менее полусотни мегов бпл-ок.. Это по-моему не нормально.. А если переводчик понятия не имеет, что такое Дельфи? Его ж кандратий схватит от интуитивности интерфейса..
S>Во-первых, переводчик для нормальной работы должен видеть контекст — окно или что там будет. Можно, конечно, вырезать и послать ему просто набор строковых констант — и, полагаю, не особо сложно — но результат будет соответствующим.
Localizer и набор скриншотов обычно не вызывают инфарктов у переводчиков. Даже боюсь представить сколько бы стоил перевод приложения с помощью ETM..
S>Так я и хочу показать, что это единственный аргумент. А чтобы он был решающим, нужна толпа внедренцев. А если есть толпа внедренцев — есть и куча успешных продаж, и соответствующие деньги.
Вы знаете, сколько стоит провести исследование лекарства на пациентах? Вы знаете сколько стоят програмные продукты в этой области? Речь идёт совсем не о продажах, а результат будет заведомо успешный.
Hет никакой речи о продажах, речь идёт о частых изменениях и пополнениях в интерфейсе.
D>>Я не понимаю, почему такое отторжение? S>Хм. Трудно сказать, на самом деле Возможно, оттого, что почему-то тема "а как бы написать свою дельфу" почему-то довольно популярна среди малограмотных коллег и вызывает уже полуавтоматическую реакцию.
Вотолько посылки у таких порывов немного различны.
D>>Зато когда будет всё готово — тогда лепи и лепи себе приложения да апдейты к ним
S>Именно. А без этого можно лепить приложения уже прямо сейчас
Ну да, а потом перелепливать и перелепливать..
S>Кстати, еще один момент — про студентов. Я в свое время отказался от довольно денежного предложения на Гупту. Потом — на ABAP. По одной простой причине: я не буду связываться с "боковой веткой", после которой я выйду искать следующую работу крупным знатоком никому не нужной хрени. И вменяемые "студенты", полагаю, будут думать так же.
Студенты — народ подневольный, что скажешь, то и будут делать. Но всё равно будут гордо задирать нос и бубнить "Java и Unix руллзз, Windows абы сдох".
Здравствуйте, Dimonka, Вы писали:
D>Доброго времени суток. D>Меня всё мучает идея создания некоего универсального движка для создания и управления формами (видами, экранами). D>Основная мысль — сделать что-то на подобие Дельфи:
D>* Редактор форм D>* Редактор компонент (Инспектор + визуальные прибамбасы) D>* Редактор скриптов D>* Связи скриптов и событий у компонент D>* Рантаймовая часть, которая всё это дело будет запускать в приложении.
D>Всё вроде не сложно. D>Все отдельные части как бы есть: TMS Scripter Studio, Greatis Runtime Fusion, DevExpress Subscription , но возникают следующие проблемы: D>- Сохранение форм / скриптов итд D>- Возможность гибкой локализаци (её отсутствие скорее) D>- Красивая связь событий и скриптов (Писать оболочки для всех компонент, которые будут отвечать за связь между событиями и реакции на них скриптов?) D>- Та же проблема с сохранением (делать на каждый компонент сохранялку/загружалку? или воспользоваться встроеной сериализацией)
D>Может есть уже что-то готовое?
помнится сам я это делал, но замучился.
Но потом прочитал в книге "DELPHI 6 и технология COM" про msscript.
Оказывается нет никаких проблем в какомнить файле писать код JScript который будет запускать наша программа, передавая в параметре ссылку на объект реализующий нужный интерфейс не помню какой (но если нужно сам найдешь).
и в этом коде можно писать добовление всяких кнопочек и т.д., одним словом СОМ. А преимущества уж не буду перечислять, все о них догадываются.
Здравствуйте, Slava Antonov, Вы писали:
SA>А вот если вы уже опытны в С, Паскале и других декларативных языках то SA>писать на прологе становится очень трудно, т.к. нужно вывернуть мозги SA>наизнанку
Я бы отметил обратный эффект. Понимая процедурные языки, понять пролог нетрудно — примерно так же, как научиться генерить отчеты на каком-нибудь QuickReport-е. Надо просто помнить, что есть спрятанный от тебя движок со своими законами, а "программа", которую ты пишешь — это набор настроек/плагинов/обработчиков событий к нему.
С другой стороны, после пролога будет трудно перейти на язык, где подобного движка нет, где ты сам управляешь выполнением.
Здравствуйте, Dimonka, Вы писали:
S>>Так я и хочу показать, что это единственный аргумент. А чтобы он был решающим, нужна толпа внедренцев. А если есть толпа внедренцев — есть и куча успешных продаж, и соответствующие деньги.
D>Вы знаете, сколько стоит провести исследование лекарства на пациентах? Вы знаете сколько стоят програмные продукты в этой области? Речь идёт совсем не о продажах, а результат будет заведомо успешный. D>Hет никакой речи о продажах, речь идёт о частых изменениях и пополнениях в интерфейсе.
Хм. У меня за стенкой сидят внедренцы Oracle Applications, занимающиеся как раз частыми изменениями и пополнениями в интерфейсе.
Насколько я в курсе их расценок, трех отчетов вполне хватит, чтобы оплатить не только дельфу (если бы они ее использовали), но и ноут, на котором они мастерят эти отчеты.
D>Вотолько посылки у таких порывов немного различны.
Безусловно. Поэтому и говорю "трудно сказать".
D>>>Зато когда будет всё готово — тогда лепи и лепи себе приложения да апдейты к ним S>>Именно. А без этого можно лепить приложения уже прямо сейчас D>Ну да, а потом перелепливать и перелепливать..
А какая разница, "перелепливать" скрипт или тот же скрипт, но оформленный как модуль? Если, конечно, не вспоминать о надежности технологии в том и в другом случае? Если вспоминать — скрипт не тянет.
D>Студенты — народ подневольный, что скажешь, то и будут делать.
Я видел работающие и даже неплохо работающие проекты с таким отношением к персоналу. Но действительно успешных — пока не видел. Не знаю как в .de, но в .msk найти человека, способного долго и хорошо выполнять дурацкую работу — дело весьма тяжелое. И тут имхо стоит ориентироваться не на студентов, а скорее на "пенсионеров" — каких-нибудь дам-фокспрошниц за сорок.
Здравствуйте, Dimonka, Вы писали:
D>Доброго времени суток. D>Меня всё мучает идея создания некоего универсального движка для создания и управления формами (видами, экранами). D>Основная мысль — сделать что-то на подобие Дельфи:
D>* Редактор форм D>* Редактор компонент (Инспектор + визуальные прибамбасы) D>* Редактор скриптов D>* Связи скриптов и событий у компонент D>* Рантаймовая часть, которая всё это дело будет запускать в приложении.
D>Всё вроде не сложно. D>Все отдельные части как бы есть: TMS Scripter Studio, Greatis Runtime Fusion, DevExpress Subscription , но возникают следующие проблемы: D>- Сохранение форм / скриптов итд D>- Возможность гибкой локализаци (её отсутствие скорее) D>- Красивая связь событий и скриптов (Писать оболочки для всех компонент, которые будут отвечать за связь между событиями и реакции на них скриптов?) D>- Та же проблема с сохранением (делать на каждый компонент сохранялку/загружалку? или воспользоваться встроеной сериализацией)
D>Может есть уже что-то готовое?
, но возникают следующие проблемы:
