[Last Call] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 613
  • Last Modified:

NotesDocument in Class requires an update

Following is spoiling my good mood:

I have a NotesUIDocument open (either create or edit). Its form loads a LS library. This library contains a class that handles activities taking place on the form. The class contains vars holding the NotesUIDocument and the NotesDocument.
All well so far.
At a certain point a sub in the class launches an agent, passing the NotesDocuments noteid as parameter.
The agent changes a field value (just a simple 1st test), saves, retrieves the modified field's value again and writes it to a file (for debugging). Clearly the agent writes the correct value to the correct field in the correct document.
Then the agent is ready and the code in the class' sub continues.
I have no lost all traces to the modified field. Saving either the NotesDocument or the NotesUIDocument would make me lose the modified fields value.

What should I do to "refresh" those two? Reloading the NotesUIDocument doesn't help....
0
CRAK
Asked:
CRAK
  • 6
  • 4
  • 3
  • +1
1 Solution
 
Sjef BosmanGroupware ConsultantCommented:
Hm, indeed, to cache or not to cache...

Why launch an agent? Can't you put the code of the agent in a script library and then just call MyAgent?

And there's the Reload-method.
0
 
mbonaciCommented:
Hi CRAK,
I suggest you to set the NotesDocument again after the agent has finished using the doc's noteID (or UNID) which you've sent to the agent.

Before that call:
    Set notesDoc = Nothing

Now the lib will hold the correct doc. This happens because the NotesDocument variable holds the copy of the document object.


Hope this helps,
Marko
0
 
CRAKAuthor Commented:
Boy, you guys are fast! Coincidence or bored?  ;-))


Sjef,

I'm building a workflow... states, actions, groups, who can do what and when.... all defined in documents.
A LS framework should be able to handle most common steps, but in a few circumstances we will need code to make tougher decisions. It's probably easier to start off at a back-end notesdocument than to start fooling around in the existing framework.
Adding the agent's code to a library may cause side effects like duplicate definitions (even for imported constants).
Reload doesn't work.... tried that before I posted the question.
A similar workflow (imported java) does the same trick perfectly. Different problem, however: where's the source nowadays? ;-((


Marko,

I'll give your suggestion a try now. I did try to open NotesDocument in an additional var, but that didn't work before.
I guess that's what Sjef wrote about: "to cache or not to cache..."

Be back soon....
0
What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

 
CRAKAuthor Commented:
Nope....
I retrieved the noteid (string), closed NotesUIDoc, set both Me.ndThis and Me.uidThis to Nothing, launched the agent (includes a save) and retrieved the NotesDocument again (by noteId). The updated value doesn't show.
If I quit the debugger there and look at the documents properties from a view, then it's obvious that the agent ran ok!
0
 
Sjef BosmanGroupware ConsultantCommented:
I think it's because the Agent Manager and the Database Server are two different processes, each with their own cache. Do you have your architecture written down on paper? Aren't you by any chance optimizing the design before the analysis is complete? Or is it an existing application?

I'd go for eleminating the side-effects, as you call them.
0
 
CRAKAuthor Commented:
I'm (re)building this thing new. Not that much architecture yet.
What analysis? All I have to start from is following remark:
"You need to create a new workflow, similar to (...), where we can put out apporoval cycle for (...) in. Later on we will need another workflow that will look a lot like it."

I'll try to reset the database object as well. If that doesn't help I'll try to reinitiate the class object....

Should I look at this caching thing in a similar way as a server running several agent handles, one unaware of what the other is doing?
0
 
Sjef BosmanGroupware ConsultantCommented:
Indeed, two different processes running concurrently, each in its own memory. Poor design... ;)

If that's all you have, then follow the old methods based on the development cycle (SDM-like). Write a requirements specification, that tries to describe in your words what they want. From there, write your analysis, then comes the design with agents and other toys, etc etc. I know, prototyping is more fun, but when things get complex and someone gets the idea that the prototype looks like what they want to have and starts using it, then you try to say that they can't use it...

You know that there is (or rather: was) a Notes template with workflow in it? There's also one on OpenNTF:
    http://www.openntf.org/projects/pmt.nsf/0/daa2390d1ada8b7a85256bed008191a0?OpenDocument&Click=
0
 
marilyngCommented:
Hi CRAK,
You know I had this same problem, and solved it by looking very carefully at the notes template classes.. here's what I do, I only instantiate the UIDOC at the top of the class, and then declare the doc in the actual module, and as marko suggests, destroy the doc at the end of the module.

If I declare the doc at the top of the class library, then it is cached.  Also, tracking the reload values helps to show the new values in the UIDOC.  If you're passing to the agent, try passing the uidoc, and reinitialize the doc.

Regards!
0
 
CRAKAuthor Commented:
You could be on to something, Marilyn.
In the New-sub of the class I immediately store the NotesUIDocument in a public var AND its NotesDocument in another.
Hmmm..... I have taken 2 days off to look after the kids; this'll continue to itch untill friday!  ;-((

I was already thinking of surrendering:
Have the agent to run on a copy of the document. Locate this copy in the calling sub, copy all fields and mark the copy for deletion (by another agent in case the user doesn't have these privileges). Probably another bumpy road.

I'll let you know!
0
 
marilyngCommented:
Yeah, I did the same thing, instantiating me.uidoc and me.doc, but realized since I was updating documents on the various events I needed to instantiate me.ws and me.uidoc only, although I usually add me.session and me.thisUser, and me.db

So all I did was declare the public variable doc, but, of course when you declare it in public, it's going to be cached, so if you have a public function postopen(uidoc as notesDocument) as boolean
   set me.doc = uidoc.document
'   and at the end
    set me.doc = nothing or delete me.doc  << which really becomes necessary if you declare it at the top of the class.
end function


Alternatively, you can skip declaring doc at the top of the class, and only instantiate it at the top of the function or sub.
 
0
 
CRAKAuthor Commented:
Wow... that still wasn't easy to archieve.
I removed all instances of NotesDocument (except the one in the agent of cource), closed the open document, set UIDoc to Nothing etc. Still had trouble! I started blaming the open document: despite my "me.UIDoc.Close" it remained open untill the script ended (at least with the debugger open).
Then, inspired on Marilyn's last post, I tried a "Delete Me.uidThis" (yes, the NotesUIDocument!; after me.UIDoc.Close of course).
That worked!
Thanks!
0
 
CRAKAuthor Commented:
FYI:
Just for the....  ehhh... "fun" of it, I reintroduced declaration and initialisation of Me.ndThis, the UIdocument's back-end.
It still works!
It MUST be the delayed closure of the open UIdoc that is causing this trouble, updating the back-end.
0
 
marilyngCommented:
Then we need additional methods...

baseballbat me.doc,
stompon me.doc
closedarnitall me.doc,
strangleandbeatyouclose me.doc

I feel your pain, had to do the same thing, I've even gone as far as to delete the session and workspace.  
OUTOUTDAMNEDSPOT me.macbethdoc
0
 
Sjef BosmanGroupware ConsultantCommented:
I prefer
    smother me.doc
 ;)
0

Featured Post

Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

  • 6
  • 4
  • 3
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now