• 15 апреля стартует «Курс «SQL-injection Master» ©» от команды The Codeby

    За 3 месяца вы пройдете путь от начальных навыков работы с SQL-запросами к базам данных до продвинутых техник. Научитесь находить уязвимости связанные с базами данных, и внедрять произвольный SQL-код в уязвимые приложения.

    На последнюю неделю приходится экзамен, где нужно будет показать свои навыки, взломав ряд уязвимых учебных сайтов, и добыть флаги. Успешно сдавшие экзамен получат сертификат.

    Запись на курс до 25 апреля. Получить промодоступ ...

Событие Querysave и вызов Doc.save

  • Автор темы SkinGreek
  • Дата начала
S

SkinGreek

Доброго времени суток.

Хотелось бы спросить совета по решению такой траблы.
В форме есть автовычисляемые поля, вычисляются они с помощью LS(на собаках я уверен что такое не сделаешь).
Сначала я внес код вычисления в событие Querysave, но в последсвии мен необходимо создавать документы по данной форме из LS(в агенте LWF).
Ясно что Querysave работает ток при работе с UI. Вставлять код вычислений этих полей во все места где документ создается я считаю дурацкой идеей хотелось бы чтоб о вычислении полей знала лишь форма.
Есть ли какие нить изощрения минимизирующие познания создающего кода о создаваемым им документе.
таких форм несколько потому писать несколько MySave() тоже как то не так.
 
O

Omh

Medevic
+100

Меня вообще бесит: понатыкают скриптов на форму, под кнопку и ещё в какую-нибудь жэпу.
Потом надо использовать этот скрипт откуда-то извне, так мало, что его перетаскивать надо, он ещё и глобальные переменные юзает.
Тьфу!

Последнее сказано не по отношению к SkinGreek, а так, крик души.
 
S

SkinGreek

Omh
Я с вами согласен в этом крике)), но этот подход лотус сам провоцирует, так же как и делфи. поэтому это можно назвать "делфийский синдром". Лично я там где вижу именно библиотечные функционалы, то я их несомненно засуну в библиотеку(но бывает и лениво конечно, грешен;))). а тут просто напросто хотелось инкапсулировать логику в форме, так как она относится только к этой форме.

Medevic
Вот чтоб не плодить библиотеки(как сущности LN) ток недавно появилась идея создать одну общую библиотеку с базовым классом "BaseDocument" который содержал бы документ, и БД. В нем метод отдачи NotesDocument'a создания документа, и абстрактный метод "CalcFields".
Во второй библиотеке создавать классы-наследники с переопределением последнего метода, в котром и был бы инкапсулирован код калькуляции таких филдов. Тогда можно будет в событии написать ...
Код:
new ConcrateDoc1(curdoc).CalcFields()
а в коде создания ...
Код:
BaseDocument newdoc = new ConcrateDoc1().CreateNew()
newdoc.getDocument().ReplaceItemValue("Bla1", "Hi")
newdoc.CalcFields()
Единственное редактор LN делает все чтоб писать длинный LS код в одной библиотеке было как можно не удобней;) (с INCLUDE директивой пока не разобрался, и скорей всего не разберусь ибо это мой последний проект на лотусе).А библиотеку для каждой формы это жирновато всеж:(
Потому и спросил как бы так по проще сделать и с сохранением структуризации и инкапсуляции логики.

All

Спасиб за советы и стимул не пихать все в ж..., хотя в лотусе это весьма сложно сделать;)
 
A

Akupaka

Меня вообще бесит: понатыкают скриптов на форму, под кнопку и ещё в какую-нибудь жэпу.
Потом надо использовать этот скрипт откуда-то извне, так мало, что его перетаскивать надо, он ещё и глобальные переменные юзает.
Тьфу!
не скажу, что я абсолютно против, но я бы сказал, что это не так уж и плохо.
а то, что нотес позволяет это сделать, то это скорее плюс, нежели минус.
каждый пишет в своем стиле, кому-то приемлимо писать "на форме", кому-то в библиотеках, плюсов и минусов у каждого способа можно найти.
и назвать это "дельфийским синдромом" как-то неверно абсолютно, я лично, кроме явы щас и не вспомню языка, который этого не позволяет (если грить о наиболее употр*цензура*емых языках)... :)
имхо!

зы: еще скажу, если кому-то достался чей-то код, то как бы плохо он не выглядел, нужно уважать чужой труд! т.к. у каждого из нас есть свои, причем, ощутимые ляпы!
 
S

SkinGreek

Назвав его "дельфийским синдромом" я имел ввиду целую методолгию разработки ПО(событийно ориентированый подход)
И началось это с делфи. Все формбилдеры такие как VC++, ASP.NET и тд построены на подобном подходе. Такой подход не плох просто он поощряет новичков писать "Magic PushButton" где надо и где не надо. Это усложняет ПО.
В Java нет форм билдеров но есть JSF или Свинг которые тоже построены на той же стратегии. там есть нечто подобное ивентов OnClick. Но новичкам в Java сразу советуют кучу книг такие как "рефакторинг" фаулера и "паттерны" гоф. Это уменьшает соблазн рамазывать функционал по всем частям программы.

Это тоже было ИМХО.
Так как я вредный глядя, как на чужой так и на свой плохой код я очень сильно ругаюсь, бывает даже матом. Но уважение к труду от этого не уменьшается.
 
A

Akupaka

ну, это призвано упростить разработку, но нагружает ПО кучей лишнего кода...
значит я не так понял, что подразумевалось под термином "д.синд" :)
на счет с кого началось, то не буду спорить, я первые версии IDE не рассматривал, хотя была помню еще под т.паскалем библиотечка, позволяющая строить "оконный" интерфейс...
а почему нету у явы форм билдеров? на сколько мне известно, то есть IDE, в которых можно разрабатывать формы визуально... либо я, снова таки, не понял термина "форм билдер" :)
т.е. я хочу сказать, что это не подход в программировании, это подход в разработке УИ приложений, зависящий от возможностей IDE, а не языка...
надеюсь, я понятно выразил свою мыслю ))

эээ, я тоже вредный, я тоже ругаюсь и на себя и на остальных, просто хотел напомнить, что надо друг друга уважать :)
 
S

SkinGreek

а почему нету у явы форм билдеров? на сколько мне известно, то есть IDE, в которых можно разрабатывать формы визуально... либо я, снова таки, не понял термина "форм билдер"
скорее я не прав в этом отношении. свинг не писал и не пользовал возможности IDE.
под "форм билдером" я имел ввиду как в делфи перетаскивание элементов нажатие на кнопочки и авто генерация обработчиков событий.
Так как работал в основном с Web таких возможностей IDE не встричал, и как то я не расстраиваюсь по этому поводу.
Ладно спорить наверное не бум ни в терминах ни в подходе к программированию. Главное чтоб нам нравилось как пишем и что пишем, и чтоб ухи не горели когда дашь человеку поддерживать свой код)))
очень жаль конечно что нет хороших Best Practices в лотусе, не хватает мне как новичку. А по созданным стандартным БД шерстить просто не возможно, особенно по началу когда вообще не знаешь как искать.
Спасибо за помощь и диалог.
 
A

Akupaka

на счет Best Practices, то они есть... но в насколько удобном виде - вопрос :)

короче гря, смотри на IBM developerworks там есть много Redbook 'ов, еще есть журнал The View, еще SearchDomino.com (http://searchdomino.techtarget.com) и много другого...
 
Мы в соцсетях:

Обучение наступательной кибербезопасности в игровой форме. Начать игру!