Мысли по сабжу.

awex · February 2004

HI !!!
После некоторого опыта практического применения забжа возникли некоторые мысли привеленные ниже.

1. TfsScript

1.1. Директива Uses. Жестко берет текст модуля из файла с именем идентичным с именем модуля, что мне кажется совсем уж не гибко.
Оптимально было бы у TfsScript добавить событие типа:
OnIncludeUnit(const Name: string; var Text: TStrings)А откуда брать текст подключаемого юнита пусть решает пользующий компонент, не сам компонент.

1.2. function AddClass
По умолчания данная функция автоматически регистрирует все published свойства импортируемого класса. Но на практике часто бывает, что все published свойства регистрировать как раз и не нужно (типа BiDiMode и т.д.).
Неплохо бы былобы к примеру нечто подобное:
function AddClass(AClass: TClass; const Ancestor: string; AutoReqPublishedProperty: Boolean = True) И соответсвенно function AddPublishedProperty(const Name: string)И можно будет ручками указать, что именно нужно импортить.

2. TfsSyntaxMemo
2.1. Неплохо было бы автоматическое извлечение Keywords для TfsSyntaxMemo из схемы
языка, а не из констант (PasKeywords, CppKeywords и т.д.).

2.2. Диалог TfsSynMemoSearch достаточно нестандартен с (мелкие кнопки, одним словом некрасиво как то, нестандартно) полем ввода искомого значения. Может просто заменить на стандартный InputBox или сделать более
стандартно ? (мелочь но все же..)

2.3. Replace Text

2.4. PopupMenu у TfsSyntaxMemo.
Можно ли вынести значение Caption у Item'ов в константы (или другая более
гибкая альтернатива), а то жесткое m.Caption := 'Copy' не всегда удобно.

2.5. Горизонтальная полоса прокрутки.

Спасибо за внимание.
Best Regard.

AlexTZ · February 2004

1.1. а мне кажется - нормально, не хуже чем в Delphi

1.2. лишние проперти никогда не помешают. Помешать может то, когда их не хватает.
2. SyntaxMemo - это бонусный компонент, если нужно что-то посерьезнее, советую взять SynMemo (из JEDI VCL, кажется).

awex · February 2004

HI AlexTZ !!!

>>>1.1. а мне кажется - нормально, не хуже чем в Delphi
И не лучше... Еще раз повторюсь, что это не гибко, очень не гибко. У нас допустим предполагается хранение юнитов в базе, да я думаю у большинства будет альтернативный мененеджмент юнитов.

>>>1.2. лишние проперти никогда не помешают. Помешать может то, когда их не хватает.
Не буду рассуждать про засорении области имен и т.д. но есть такие случаи, и возможность их ручной установки должна быть!!

>>>2. SyntaxMemo - это бонусный компонент
Это понятно, но ведь если приложить немного усилий в плане его доработки то в большинстве случаев отпадет нужда в сторонних компонентах, что сделает продукт более конкурентно способным, да и целостность пакета тоже…

Или авторы придерживаются позиции как в том анекдоте про "после сборки обработать напильником"??

Спасибо за внимание.

Georgy · February 2004

Hi, awex!
1.1 Преимущество скриптов в том, что их можно менять динамически, то есть скажем при выгрузке модулей из БД на конкретного клиента, загрузчик может прекрасно модифицировать код этих модулей, прописывая в uses пути и т.п.
Для скриптов в IL code это не годится. Но можно использовать скрипты совместно - в исходниках и псевдокоде, вызывая одни из других, хотя это в общем трюки.

А вот возможность для конечного пользователя поключать к скриптам DLL/BPL было бы здорово. В Genidaque (одна из реализаций VBasic для SCADA-систем) это оказалось для меня просто спасением.
Чем порадуют разработчики на этот счет?

AlexTZ · February 2004

Ничем - вызов DLL из скрипта не планируется в силу того, что нужен другой call handler (способный вызывать любую процедуру/функцию, с любым набором параметров любого типа и call convention), поддержка структур и пр.

CrusaderSX · March 2004

Georgy написал:

1.1 Преимущество скриптов в том, что их можно менять динамически, то есть скажем при выгрузке модулей из БД на конкретного клиента, загрузчик может прекрасно модифицировать код этих модулей, прописывая в uses пути и т.п.
Для скриптов в IL code это не годится. Но можно использовать скрипты совместно - в исходниках и псевдокоде, вызывая одни из других, хотя это в общем трюки...

1. Зачем писать загрузчик, если можно брать код используемого модуля напрямую из набора данных?
В моей программе, использующей JvInterpreter (ранее RAI2), именно так и делается. Код, правда используется один и тот же для всех пользователей,
скрипты хранятся на сервере БД, а смысл использования скриптов в том, чтобы обеспечить собственную настройку системы для каждой конкретной организации.
2. Раз уж пошла такая пьянка... Не хватает обработчика, возвращающего и устанавливающего значение идентификатора (в том же jvInterpreter - OnGetValue, OnSetValue). Если скрипт работает, например, в контексте какого-то набора данных (поля которого заранее неизвестны), то зачем мне писать каждый раз DataSet := ..., если я могу просто писать Cost := ...

Поэтому я до сих пор использую <я уже сказал что>, несмотря на все его недостатки.

AlexTZ · March 2004

написал:

Не хватает обработчика, возвращающего и устанавливающего значение идентификатора (в том же jvInterpreter - OnGetValue, OnSetValue).

Поэтому оно и такое медленное...

CrusaderSX · March 2004

AlexTZ написал:

AlexTZ написал:

Не хватает обработчика, возвращающего и устанавливающего значение идентификатора (в том же jvInterpreter - OnGetValue, OnSetValue).

Поэтому оно и такое медленное...

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

Georgy · March 2004

Hi, CrusaderSX!

написал:

. Зачем писать загрузчик, если можно брать код используемого модуля напрямую из набора данных?
В моей программе, использующей JvInterpreter (ранее RAI2), именно так и делается. Код, правда используется один и тот же для всех пользователей,
скрипты хранятся на сервере БД, а смысл использования скриптов в том, чтобы обеспечить собственную настройку системы для каждой конкретной организации.

Под "загрузчиком" я подразумевал некоторый код, который выбирает скрипт из БД и загружает его в интерпритатор. Это в простейшем случае. Но при необходимости, перед загрузкой в интерпритатор скрипт можно модифициорвать. Большая польза от скриптов как раз тогда, когда требуются настройки кода для конкретных пользователей. А это бывает очень часто. При помощи скриптов можно оперативно изменять код пользователя как на его клиентском месте, так и на сервере, в том числе и удаленно. А если речь идет об одинаковом коде для всех клиентов, то может быть даже эффективнее делать обновления при помощи пакетов.

CrusaderSX · March 2004

>> Под "загрузчиком" я подразумевал некоторый код, который выбирает
>> скрипт из БД и загружает его в интерпритатор.
С загрузчиком ясно. Но опять-таки: используемые модули приходится выгружать в файлы? Я пытаюсь поддержать совет разработчикам добавить возможность получения текста модуля (и формы) из источника, определяемого пользователем.

>> ... может быть даже эффективнее делать обновления при помощи пакетов.
Что имеется в виду?

Georgy · March 2004

Hi, CrusaderSX!
Как правило, модули выгружаются в файлы. Но это необязательно. Скрипт (исходный текст) помещается в свойство TfsScript.Lines: TStrings, поэтому можно его загружать хоть из файла, хоть из БД, хоть динамически генерировать - примерно так:

const
  PATH = 'C:\SCRIPTS\';
  ...
  fsScript1.Parent := fsGlobalUnit;
  // загружаем из файла
  fsScript1.Lines.LoadFromFile(PATH + 'MySource.pas');
  ...
  // или выбираем из БД
  fsScript1.Lines.Text := MyDataSet.FieldByName('SCRIPT').AsString;
  ...
  // или создаем динамически
  fsScript1.Lines.Text :=
    'begin'+^M^J+
    '  ShowMessage(''Hello World!'');'+^M^J+
    'end.';
  ...
  if not fsScript1.Run then ...

Текст скрипта можно перед помещением в TfsScript.Lines как угодно модифицировать: склеивать, резать и т.п. Полезным можеть быть применение скриптов-шаблонов и ф-ций форматирования Formatxxx. Наибольшая гибкость достигается, когда операции выборки, модификации и загрузки скриптов выполняются также скриптами, а не приложением. Можно также вызывать скрипт из скрипта, для этого нужно сделать соответствующую "обертку" TfsScript.

Пакеты - см. Delphi Help "About packages". Вкратце, применение пакетов позволяет вносить изменения и расширять функциональность проекта без его перекомпиляции.

CrusaderSX · March 2004

Hi Georgy!
Ну это понятно, что текст скрипта надо присвоить свойству Lines, и его можно брать откуда угодно. И вызов другого скрипта можно сделать (у меня это давно уже работает).
Проблема в обращении к объектам (функциям, переменным), объявленным в подключенных с помощью 'uses' модулях.
Я так понял, что текст этого модуля берется интерпретатором только из файла с именем, соответствующим имени модуля.

Gloreus · March 2004

написал:

Использование форм в подключаемых модулях - тоже очень важная возможность. И было бы еще неплохо и дизайнер форм.

В самом деле, вещь очень полезная.
Планируется ли когда-нибудь?

Glotik · March 2004

to Gloreus:
Ну еще и дизайнер, объект инспектор и т.д. и т.п.
Ну ребята, вы даете.

Georgy · March 2004

To Glotik:
Да все это неплохо бы иметь. На 1й случай хотя бы механизм считывания формы, сконструированной в Delphi из *.dfm. У меня это работает в полуручном варианте, примерно так:
1.загружается форма из *.dfm (в файле имя класса заменено на TForm).
2.по именам находятся нужные компоненты.
3.им назначаются обработчики.
Как сделать иначе без правки исходников, я пока не вижу.

А что скажут разработчики?

Glotik · March 2004

to Georgy:
А купить готовые компоненты не пробовали? Есть масса сторонних разработок.

CrusaderSX · March 2004

Glotik написал:

to Georgy:
А купить готовые компоненты не пробовали? Есть масса сторонних разработок.

Подскажете, какие именно? Я вообще-то искал, но наверное, не очень тщательно.

awex · March 2004

2Glotik>>
Дизайнеров форм и ObjectInspector существует множество...

Вот несколько:

Dream Collection (Комерч.)
http://www.dream-com.com/
Достаточно мощный и навароченный пакет (но можно и покупать по отдельности).

RAlib (Бесплатна, вошла в состав JEDI VCL)
http://search.msn.com/results.aspx?srch=105&FORM=AS5&q=RAlib

P.S.: В конце можно пошарить по торри:
http://www.torry.net/quicksearchd.php?SID=...igner&Title=Yes

bakh · March 2004

awex написал:

RAlib (Бесплатна, вошла в состав JEDI VCL)
http://search.msn.com/results.aspx?srch=105&FORM=AS5&q=RAlib

Особенно порадовала найденная ссылка на Angelika Russian Marriage Agency Network - About Us

CrusaderSX · March 2004

awex написал:

RAlib (Бесплатна, вошла в состав JEDI VCL)

В RALibe давно уже дизайнера убрали. чтобы не было проблем из-за лицензионных ограничений.

А другого бесплатного ничего нет. Если покупать каждую компоненту - недолго и разориться, поэтому в последнее время предпочитаю бесплатные.
(хотя, возможно, это мои личные проблемы)

awex · March 2004

Можно постараться написать самому...
(Хотя с мой точки зрения проще купить готовое...

P.S.:
Как то давненько конторка DevExpress проводила конкурс среди програмистов, конкурсным задание было как раз написание дизайнера....
(http://www.dxrussia.ru/conkurs.php)
Можно посмотреть варианты решений задания (http://www.aqa.com.ru/results.asp) и попытаться написать самому.

За пример можно всять например это:
http://www.aqa.com.ru/files/12.zip
http://www.aqa.com.ru/files/35.zip

Мысли по сабжу.

Комментарии

Оставить комментарий