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

awexawex
отредактировано 00:50 Раздел: FastScript
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.

Комментарии

  • AlexTZAlexTZ
    отредактировано 00:50
    1.1. а мне кажется - нормально, не хуже чем в Delphi ;)
    1.2. лишние проперти никогда не помешают. Помешать может то, когда их не хватает.
    2. SyntaxMemo - это бонусный компонент, если нужно что-то посерьезнее, советую взять SynMemo (из JEDI VCL, кажется).
  • awexawex
    отредактировано 00:50
    HI AlexTZ !!!

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

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

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

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

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

    А вот возможность для конечного пользователя поключать к скриптам DLL/BPL было бы здорово. В Genidaque (одна из реализаций VBasic для SCADA-систем) это оказалось для меня просто спасением.
    Чем порадуют разработчики на этот счет?
  • AlexTZAlexTZ
    отредактировано 00:50
    Ничем - вызов DLL из скрипта не планируется в силу того, что нужен другой call handler (способный вызывать любую процедуру/функцию, с любым набором параметров любого типа и call convention), поддержка структур и пр.
  • CrusaderSXCrusaderSX
    отредактировано 00:50
    Georgy написал:
    1.1 Преимущество скриптов в том, что их можно менять динамически, то есть скажем при выгрузке модулей из БД на конкретного клиента, загрузчик может прекрасно модифицировать код этих модулей, прописывая в uses пути и т.п.
    Для скриптов в IL code это не годится. Но  можно использовать скрипты совместно - в исходниках и псевдокоде, вызывая одни из других, хотя это в общем трюки...
    1. Зачем писать загрузчик, если можно брать код используемого модуля напрямую из набора данных?
    В моей программе, использующей JvInterpreter (ранее RAI2), именно так и делается. Код, правда используется один и тот же для всех пользователей,
    скрипты хранятся на сервере БД, а смысл использования скриптов в том, чтобы обеспечить собственную настройку системы для каждой конкретной организации.
    2. Раз уж пошла такая пьянка... Не хватает обработчика, возвращающего и устанавливающего значение идентификатора (в том же jvInterpreter - OnGetValue, OnSetValue). Если скрипт работает, например, в контексте какого-то набора данных (поля которого заранее неизвестны), то зачем мне писать каждый раз DataSet := ..., если я могу просто писать Cost := ...

    Поэтому я до сих пор использую <я уже сказал что>, несмотря на все его недостатки.
  • AlexTZAlexTZ
    отредактировано 00:50
    написал:
    Не хватает обработчика, возвращающего и устанавливающего значение идентификатора (в том же jvInterpreter - OnGetValue, OnSetValue).

    Поэтому оно и такое медленное...
  • CrusaderSXCrusaderSX
    отредактировано March 2004
    AlexTZ написал:
    AlexTZ написал:
    Не хватает обработчика, возвращающего и устанавливающего значение идентификатора (в том же jvInterpreter - OnGetValue, OnSetValue).

    Поэтому оно и такое медленное...
    Не совсем понял, почему "поэтому"?
    Ну да ладно, не буду придираться к словам...
    Хочу подчеркнуть, что не пытаюсь продвигать конкурирующий продукт на форуме FastScript. Я слежу за развитием вашего движка с момента выхода первой версии и перейду на него сразу же, как только будут реализованы необходимые мне функции. Использование форм в подключаемых модулях - тоже очень важная возможность. И было бы еще неплохо и дизайнер форм.
  • GeorgyGeorgy
    отредактировано 00:50
    Hi, CrusaderSX!
    написал:
    . Зачем писать загрузчик, если можно брать код используемого модуля напрямую из набора данных?
    В моей программе, использующей JvInterpreter (ранее RAI2), именно так и делается. Код, правда используется один и тот же для всех пользователей,
    скрипты хранятся на сервере БД, а смысл использования скриптов в том, чтобы обеспечить собственную настройку системы для каждой конкретной организации.
    Под "загрузчиком" я подразумевал некоторый код, который выбирает скрипт из БД и загружает его в интерпритатор. Это в простейшем случае. Но при необходимости, перед загрузкой в интерпритатор скрипт можно модифициорвать. Большая польза от скриптов как раз тогда, когда требуются настройки кода для конкретных пользователей. А это бывает очень часто. При помощи скриптов можно оперативно изменять код пользователя как на его клиентском месте, так и на сервере, в том числе и удаленно. А если речь идет об одинаковом коде для всех клиентов, то может быть даже эффективнее делать обновления при помощи пакетов.
  • CrusaderSXCrusaderSX
    отредактировано 00:50
    >> Под "загрузчиком" я подразумевал некоторый код, который выбирает
    >> скрипт из БД и загружает его в интерпритатор.
    С загрузчиком ясно. Но опять-таки: используемые модули приходится выгружать в файлы? Я пытаюсь поддержать совет разработчикам добавить возможность получения текста модуля (и формы) из источника, определяемого пользователем.

    >> ... может быть даже эффективнее делать обновления при помощи пакетов.
    Что имеется в виду?
  • GeorgyGeorgy
    отредактировано 00:50
    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". Вкратце, применение пакетов позволяет вносить изменения и расширять функциональность проекта без его перекомпиляции.
  • CrusaderSXCrusaderSX
    отредактировано 00:50
    Hi Georgy!
    Ну это понятно, что текст скрипта надо присвоить свойству Lines, и его можно брать откуда угодно. И вызов другого скрипта можно сделать (у меня это давно уже работает).
    Проблема в обращении к объектам (функциям, переменным), объявленным в подключенных с помощью 'uses' модулях.
    Я так понял, что текст этого модуля берется интерпретатором только из файла с именем, соответствующим имени модуля.
  • GloreusGloreus
    отредактировано 00:50
    написал:
    Использование форм в подключаемых модулях - тоже очень важная возможность. И было бы еще неплохо и дизайнер форм.

    В самом деле, вещь очень полезная.
    Планируется ли когда-нибудь?
  • GlotikGlotik
    отредактировано 00:50
    to Gloreus:
    Ну еще и дизайнер, объект инспектор и т.д. и т.п.
    Ну ребята, вы даете.
  • GeorgyGeorgy
    отредактировано 00:50
    To Glotik:
    Да все это неплохо бы иметь. На 1й случай хотя бы механизм считывания формы, сконструированной в Delphi из *.dfm. У меня это работает в полуручном варианте, примерно так:
    1.загружается форма из *.dfm (в файле имя класса заменено на TForm).
    2.по именам находятся нужные компоненты.
    3.им назначаются обработчики.
    Как сделать иначе без правки исходников, я пока не вижу.

    А что скажут разработчики?
  • GlotikGlotik
    отредактировано 00:50
    to Georgy:
    А купить готовые компоненты не пробовали? Есть масса сторонних разработок.
  • CrusaderSXCrusaderSX
    отредактировано 00:50
    Glotik написал:
    to Georgy:
    А купить готовые компоненты не пробовали? Есть масса сторонних разработок.
    Подскажете, какие именно? Я вообще-то искал, но наверное, не очень тщательно.
  • awexawex
    отредактировано 00:50
    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

  • bakhbakh Санкт-Петербург
    отредактировано 00:50
    awex написал:
    RAlib (Бесплатна, вошла в состав JEDI VCL)
    http://search.msn.com/results.aspx?srch=105&FORM=AS5&q=RAlib
    Особенно порадовала найденная ссылка на Angelika Russian Marriage Agency Network - About Us ;)
  • CrusaderSXCrusaderSX
    отредактировано 00:50
    awex написал:
    RAlib (Бесплатна, вошла в состав JEDI VCL)
    В RALibe давно уже дизайнера убрали. чтобы не было проблем из-за лицензионных ограничений. ;)
    А другого бесплатного ничего нет. Если покупать каждую компоненту - недолго и разориться, поэтому в последнее время предпочитаю бесплатные.
    (хотя, возможно, это мои личные проблемы)
  • awexawex
    отредактировано 00:50
    Можно постараться написать самому...
    (Хотя с мой точки зрения проще купить готовое... ;)

    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

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

Многофункциональный текстовый редактор. Чтобы отредактировать стиль параграфа, нажмите TAB, чтобы перейти к меню абзаца. Там вы можете выбрать стиль. По умолчанию не выбран ни один стиль. Когда вы выберете текст, появится встроенное меню форматирования. Нажмите TAB, чтобы войти в него. Некоторые элементы, такие как многофункциональные вставки ссылок, картинок, индикаторов загрузки и сообщений об ошибок могут быть вставлены в редактор. Вы можете перемещаться по ним, используя стрелки внутри редактора и удалять с помощью клавиш delete или backspace.

Начало • FastScriptКомментировать как ...

© Vanilla Keystone Theme 2024