nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Navigation, autonaming & prevent overwrite

nipper

OK, so I am trying to figure the best way to handle this.

I have a navigation menu, that creates top nav, left nav and bread crumbs.

So I create it with menu/Item -> /some/dir/index.html

In my detail page DCR, I have a select list that the user chooses menu-Item (and thus I know the generated page and can determine the DCR name). All well and good.

So I use IWDCRInfo.setDCRName(myDcrName); to set the name. But if I create a new DCR and one is already there it overwrites and does not ask if you want to or not. OK, between locking and versioning that is not horrible but not perfect.

I have call server code to see if there is a conflict. So I can popup and reject the name. Maybe a better solution. I suppose I could write a popup that asks if it should overwrite, yes or no.

Anyone try any other options ? Is there a way to use setName without overwrite set ?

Andy

Find more posts tagged with

Comments

ISCBorisB

I have call server code to see if there is a conflict. So I can popup and reject the name. Maybe a better solution. I suppose I could write a popup that asks if it should overwrite, yes or no.

Anyone try any other options? Is there a way to use setName without overwrite set ?Andy

I once used setDCRName callback feature + onSave flagging to accomplish something similar. Like that:

IWDCRInfo.setDCRName(myDcrName, checkStatus); 
. . .

//---------------------------------------------------------------
function checkStatus() {
   var status = IWDCRInfo.getStatus();

   if (status == IWDCRInfo.PENDING) {
      //Check again in 2 sec
      setTimeout("checkStatus()",2000);
   }
   else if (status == IWDCRInfo.AVAILABLE) {
      if (!confirm("DCR Exists. Do you want to override it?")) {
         // Restore Original name, Set "Bad Name" Flag to check onSave 
         // and reject, etc...
      }
   }
   else if (status == IWDCRInfo.UNAVAILABLE) {
      alert("New DCR");
   }
   else if (status == IWDCRInfo.ERROR) {
      alert("Can not set DCR Name");
   }
   else {
      alert(status + " - That should not have happened!");
   }
}

TestReport.rptdesign

vahu

Hi nipper,

I did not quit understand the answer in the other reply, but i have used the following approach several times before:

1. Call checkName() function in onSave()
2. checkName function makes a callServer to a perl script
3. use simple -f/-d in perl to check for existence (please remember that you can not have a folder with name x and in the same location create a file named x)
4. Return value to checkName_callbak
5. If needed prompt user for whether overwrite is ok, otherwise return false in OnSave and ask the user to specify another name

Hope this helps :-)

.Saya

moonkhanna

I once used setDCRName callback feature + onSave flagging to accomplish something similar. Like that:

IWDCRInfo.setDCRName(myDcrName, checkStatus); 
. . .

//---------------------------------------------------------------
function checkStatus() {
var status = IWDCRInfo.getStatus();

if (status == IWDCRInfo.PENDING) {
//Check again in 2 sec
setTimeout("checkStatus()",2000);
}
else if (status == IWDCRInfo.AVAILABLE) {
if (!confirm("DCR Exists. Do you want to override it?")) {
// Restore Original name, Set "Bad Name" Flag to check onSave 
// and reject, etc...
}
}
else if (status == IWDCRInfo.UNAVAILABLE) {
alert("New DCR");
}
else if (status == IWDCRInfo.ERROR) {
alert("Can not set DCR Name");
}
else {
alert(status + " - That should not have happened!");
}
}

Hi Bo,

This does not help. Could you please explain tghe functionality of this function.

Best Regards,

Munish Khanna

moonkhanna

Hi Bo,

This does not help. Could you please explain tghe functionality of this function.

Best Regards,

Munish Khanna

Hi Bo,

Please ignore. it worked .... Fabulous solution.. Thanks!

Adam Stoller

Hi Bo,

Please ignore. it worked .... Fabulous solution.. Thanks!

Do you understand how/why it works - or are you just happy that someone spoon-fed you working code and satisfied with that?

Also - as you seem so fond of saying: "If your issue is resolved, please close the thread" -- however I prefer to make sure the issue is really resolved before doing / requesting that.

moonkhanna

Do you understand how/why it works - or are you just happy that someone spoon-fed you working code and satisfied with that?

Also - as you seem so fond of saying: "If your issue is resolved, please close the thread" -- however I prefer to make sure the issue is really resolved before doing / requesting that.

hi Adam,

Thanks for your nice response. Actually, the issue is not resolved. I was just searching the thread to post back again. Ah yes, I understand how it works and got its reference from the FORM API guide..

Neways, heres the deal. I am able to makeout with Bo's code, that there is an existing DCR with the same name but what do we return to the setDCRName function so as to stop it from naming the DCR with the same name..

I have tried various things but that does not seem to be working.. Also, as per the FORM API Guide, the callback is done after the DCR save but that does not seem to be happening..The callback is being called before DCR save.. in which case, we should be able to stop the function but how? Any ideas would be highly appreciated.

Best Regards,

Munish Khanna

moonkhanna

hi Adam,

Thanks for your nice response. Actually, the issue is not resolved. I was just searching the thread to post back again. Ah yes, I understand how it works and got its reference from the FORM API guide..

Neways, heres the deal. I am able to makeout with Bo's code, that there is an existing DCR with the same name but what do we return to the setDCRName function so as to stop it from naming the DCR with the same name..

I have tried various things but that does not seem to be working.. Also, as per the FORM API Guide, the callback is done after the DCR save but that does not seem to be happening..The callback is being called before DCR save.. in which case, we should be able to stop the function but how? Any ideas would be highly appreciated.

Best Regards,

Munish Khanna

Any bidders? Bo, Adam, Andy, anyone?

ISCBorisB

Any bidders? Bo, Adam, Andy, anyone?

You can not "return" anything to setDCRName, it's an asynchronous call. What you can do is (for example) declare a flag
to indicate DCR Naming state and use this flag within onSaveValid Event Handler. Something like this:

// Declare Globals
var DCRNamed = false;
...
// Note that checkStatus() should re-set DCRNamed Flag to true when appropriate
IWDCRInfo.setDCRName(myDcrName, checkStatus);
...
function handle_saveValid() {
  if (!DCRNamed) return false;
  // So far so good, Continue. If everything is fine, return true
  ....
}

Frederik

but what do we return to the setDCRName function so as to stop it from naming the DCR with the same name..

what would you like to happen? if you believe the doc, then you can call setDCRName(null) or so.

Quote. If path is null, the DCR name is explicitly unset. The callback is not executed if the path is null. The system prompts the user for a DCR name when the Save button is clicked. Unquote.

Also, as per the FORM API Guide, the callback is done after the DCR save but that does not seem to be happening..

I'm pretty sure the doc says that "The callback executes when the request completes." The request in this case is "the server request for information about that file(name)".
So in other words, when you execute setDCRName, an async request is sent to the server to find out if anything by that name exists, etc. When the results are available, the callback is executed.... this is not at all linked to a SAVE event.

Frederik

question to Boris, on your example code in 2nd post of the thread...

In a similar case, we've done the "check if file exists" with callserver CGI, rather than the simpler (less code) approach with setDCRName(name, checkStatus).
The reason being that in our case, name might include a subdirectory that doesn't exist yet in the /data location. The CGI then creates the missing directories also.

I believe we empirically found that in that case, using setDCRName was not working for us (it refused to save file because directory non-existing). Is that your experience also, or did we draw the wrong conclusions?

thanks for sharing

ISCBorisB

question to Boris, on your example code in 2nd post of the thread...

In a similar case, we've done the "check if file exists" with callserver CGI, rather than the simpler (less code) approach with setDCRName(name, checkStatus).
The reason being that in our case, name might include a subdirectory that doesn't exist yet in the /data location. The CGI then creates the missing directories also.

I believe we empirically found that in that case, using setDCRName was not working for us (it refused to save file because directory non-existing). Is that your experience also, or did we draw the wrong conclusions?

thanks for sharing

Let me clarify a little - that's what you probably meant anyway Smiley Happy

As far as I recall in the case of non-existing Directory setDCRName will run without problems and indicate "New DCR"
(status == IWDCRInfo.UNAVAILABLE). However, unless correct Path is created upfront actual "Save" will fail with
the "Invalid Path" Error.

In the case like that I would do exactly what you have done: shun setDCRName in favor of my own callSever Script to do
what I please.

moonkhanna

You can not "return" anything to setDCRName, it's an asynchronous call. What you can do is (for example) declare a flag
to indicate DCR Naming state and use this flag within onSaveValid Event Handler. Something like this:

// Declare Globals
var DCRNamed = false;
...
// Note that checkStatus() should re-set DCRNamed Flag to true when appropriate
IWDCRInfo.setDCRName(myDcrName, checkStatus);
...
function handle_saveValid() {
if (!DCRNamed) return false;
// So far so good, Continue. If everything is fine, return true
....
}

Hi Bo,

Thanks for your nice response. Yes, it seems to be working however since the callback is async, I am still facing some timeout issues.. Working to get those resolved.

Thanks very much for your help on the issue.

Best Regards,

Munish Khanna

moonkhanna

what would you like to happen? if you believe the doc, then you can call setDCRName(null) or so.

Quote. If path is null, the DCR name is explicitly unset. The callback is not executed if the path is null. The system prompts the user for a DCR name when the Save button is clicked. Unquote.

I'm pretty sure the doc says that "The callback executes when the request completes." The request in this case is "the server request for information about that file(name)".
So in other words, when you execute setDCRName, an async request is sent to the server to find out if anything by that name exists, etc. When the results are available, the callback is executed.... this is not at all linked to a SAVE event.

Hi Fredrik,

Thanks for your nice response. It does work and seems to be related to the save event. At the same time, you seem to be right, even though it does not does the save, it is somehow storing the DCRInfo regardless of what happens on the save event.

I am still working on this. Will post back with final results. Also, the setDCRName(null) mentioned in the Guide does not work to stop the setDCRName function. I tried that already.

Best Regards,

Munish Khanna

Adam Stoller

I suggest you repost the code you are using (FormAPI + callServer script) if you want any further assistance debugging the behavior you're seeing.

moonkhanna

I suggest you repost the code you are using (FormAPI + callServer script) if you want any further assistance debugging the behavior you're seeing.

Hi Adam,

Below is the code. Please let me know if you find something missing. The behaviour basically is that it saves the DCR when I click on Save the second time. The first time though, it does not save the DCR, it still saves the DCRInfo for the DCR..

function setSaveValidState()
{
setDCRName();
retVal();
if(dcrNamed == "true") {
return false;
}
else if(dcrNamed == "false")
{
return true;
}
}
function retVal()
{
if(dcrNamed == "true" || dcrNamed == "false") {
return true;
}
else {
setTimeout("retVal()",2000);
}
}

function setDCRName()
{
var dcrName = IWDCRInfo.getDCRName();
doc = IWDatacapture.getItem("/Doc/Doc/Pagetitle/Doc").getValue();
if(!dcrName)
{
IWDCRInfo.setDCRName(doc, checkStatus);
}
else if(dcrName != doc)
{
IWDCRInfo.setDCRName(doc, checkStatus);
}

return true;
}
function checkStatus() {
var status = IWDCRInfo.getStatus();

if (status == IWDCRInfo.PENDING) {
//Check again in 2 sec
setTimeout("checkStatus()",2000);
}
else if (status == IWDCRInfo.AVAILABLE) {
alert("DCR with the above Number already exists. \n The save will abort");
dcrNamed = "true";
}
else if (status == IWDCRInfo.UNAVAILABLE) {
dcrNamed = "false";
}
else if (status == IWDCRInfo.ERROR) {
alert("Can not set DCR Name");
dcrNamed = "false";
}
else {
alert(status + " - That should not have happened!");
dcrNamed = "false";
}
}

ISCBorisB

Below is the code. Please let me know if you find something missing. The behaviour basically is that it saves the DCR when I click on Save the second time. The first time though, it does not save the DCR, it still saves the DCRInfo for the DCR..

Note that setTimeout doesn't halt script execution. Rather, it *schedules* the specified call with the given delay.

After the call to setTimeout the script immediately continues, with the timer ticking on the background. So, assuming
that the initial value of your dcrNamed flag is null, it is quite possible that (for example) setSaveValidState immediately
returns nothing ('return void' if you wish). By the time your user clicks anything again though, scheduled routines were
executed, Flag has a value, etc...

moonkhanna

Note that setTimeout doesn't halt script execution. Rather, it *schedules* the specified call with the given delay.

After the call to setTimeout the script immediately continues, with the timer ticking on the background. So, assuming
that the initial value of your dcrNamed flag is null, it is quite possible that (for example) setSaveValidState immediately
returns nothing ('return void' if you wish). By the time your user clicks anything again though, scheduled routines were
executed, Flag has a value, etc...

Bo, thanks for your nice response. Does this mean that it is just not doable? Any suggestions on improving the code to accomplish the task?

Should I just go with the call server then?

nipper

Bo, thanks for your nice response. Does this mean that it is just not doable? Any suggestions on improving the code to accomplish the task?

Should I just go with the call server then?

With a callserver you could have had this working days ago, is there a particular reason you have avoided it ?

moonkhanna

With a callserver you could have had this working days ago, is there a particular reason you have avoided it ?

Hi Andy,

No, no particular reason. I went this way and was no turning back.. Anyways, I can turn back now.

Thanks Andy!

Best Regards,

Munish Khanna

ISCBorisB

Bo, thanks for your nice response. Does this mean that it is just not doable? Any suggestions on improving the code to accomplish the task?

Should I just go with the call server then?

It is certainly doable. Personally if no special Server side processing is required I prefer it to callServer.
The reason is very simple, it's all on the FormAPI side (Server portion of it certainly exists - IWOV took care
of that) whereas with the callServer it's FormAPI anyway + your own (asynchronous still!) Server side scripting.

There are several ways to perform re-synchronization. My favorite is a bit counter-intuitive, in your case it'll look like this:

1. Use IWDCRInfo.setDCRName(myDcrName, checkStatus) in onSaveValid Handler. From checkStatus use short setTimeout to run your
own Save Function using IWDatacapture.save() - you must ensure you have valid name at this point. Note that this does not
trigger onSaveValid, there is no recursion here! (it does trigger onSaveDone though). In this schema checkStatus always ends normally
leaving behind a scheduled call to either self (status PENDING) or actual Save.

2. Always return false from onSaveValid Form Handler! That will be executed immediately with the scheduled checkStatus/Saving left
behind by #1.

3. It often pays to be extra careful with re-synchronization. So, you may also want to set saveScheduled Flag and simply
ignore subsequent Save(s) if your user is too fast with the mouse. For this purpose I often use (numeric) timeoutID that
setTimeout returns - just do not forget to re-set the Flag back to 0 after actual Save!

Note that if you use callServer instead you will face slightly different flavor of that same issues, callServer is an asynchronous
call just as well. I *think* I've illustrated few of this *resynchronization* concepts (for callServer) some time ago - can't find post though

nipper

I have never had trouble with call server resync. Basically because my original thread stops when the callserver is initiated and then the callback kicks off the save itself.

something like


 IWEventRegistry.addFormHandler("onSaveValid", allowSave);

The function allowSave makes the callserver which returns to a function that does this:


  IWDCRInfo.setDCRName(dcrName);
  IWDatacapture.save(dcrName);
  IWDatacapture.redraw();

TestReport.rptdesign

ISCBorisB

I have never had trouble with call server resync. Basically because my original thread stops when the callserver is initiated and then the callback kicks off the save itself

Understood, point is you still have to re-synchronize Client / Server execution threads one way or another.

Besides, we both know that's oversimplification. What if setDCRName fails? What if callServer does not make a callback
within reasonable time or does not make it at all? What happens if you have few sequential Saves from impatient User?
None of that is rocket science of course - but has to be addressed in professional code

nipper

Besides, we both know that's oversimplification. What if setDCRName fails? What if callServer does not make a callback
within reasonable time or does not make it at all? What happens if you have few sequential Saves from impatient User?
None of that is rocket science of course - but has to be addressed in professional code

Hmm, I don't know how much I agree with that. My callserver verifies that DCR name before sending it back. So I have never had the setDCRName fail (and I do use this code in several DCRs).

If the callserver doesn't return ? OK, valid point. It happens to me during testing more often than not (my laptop has #!c:/interwoven/iw-home and on my prod server it is #!d:/interwoven/iw-home) so when I transfer code between the 2 they fail without the mod (since these are utilities that does not happen often since they seldom change).

Multiple saves ? With a working call server, no issue, if it is not working - my bad.

So maybe I *should* use a timeout to verify the callserver returned in a reasonable time, however I would rather use my time working on other issues that I KNOW need to be addressed rather than something that *could* be an issue someday.

Off my soapbox now, back to your regular scheduled programming.

Andy

Migrateduser

could someone please post the complete/final code example to do this without callServer? we have this working with a callserver but we had to add a hidden field to our DCRs, i.e.

[HTML]

[/HTML]

i dont want this due to us switching to XML dcr types - ive been trying to merge all the formapi code in this thread unsuccessfully. thanks in advance!