Using Lotus Notes designer I have created a form and added a field on that form that does a #DBColumn look up. The form then is viewed through the web browser and everything worked great.
I proceed to add another document to the database using that form, now the original documents still render in the browser fine but the new document doesn't return anything to the field.
I tried removing the #DBColumn look up and just displaying text but nothing I just get 0.
The weird thing is if I rename the field to something diferent everything works perfectly but then if I rename the field back, broken, no calculation.
Does anyone know why this is? It has happened to me with various fields through out my application. I originally thought maybe it was a reserved word thing but I now know that is not the case. I usually just rename the field and move on but there has to be an explanation. Is it a caching thing or what?
Thanks for the info!
You haven't mentioned the type of your fields Is it 'computed for display'? If you have computed for display fields in a form, and the documents already contain data stored in an item with the same name, then the computed formula is bypassed and the item value is displayed as-is.
Fields not calculating could be a caching issue. Try opening the form, edit mode, F9 to recalculate all fields.
If this does not help, close the form, press Ctrl+Shift+F9 to forcefully refresh all views in the DB (could take some time). Reopen your form, edit mode, F9. If the value shows up, try using the "nocache" parameter on your #DBColumn.
Depending on your application design, there could be a number of reasons for the problem. Perhaps the view used for lookup is not set to autorefresh or the server does not refresh often enough because of high load issues.
Related
Sorry this isn't a specific coding question, it is more of a design concept.
What is the usage case for programmatically adding and removing fields to Notes Forms e.g. NotesDocument.RemoveItem(), ie why would you add and remove fields in the background?
For many years I have designed my forms with the fields layed out on the form which are required and then hide and show as required.
By adding dynamically you can't position them and frustratingly removing them or deleting they still appear the Database Fields in Domino Designer, getting rid of them is a bit a a black art, but that's another story.
I must be missing a trick or a basic design concept. Any thoughts on best practice would be appreciated.
Many thanks.
Yes, you are missing the difference between "Fields" and "Items". A field is a design element that you can place anywhere on your form. You define how it looks, what content it contains, what datatype it is, etc.
When creating a document with the form the value of the FIELD is stored in an ITEM in the resulting NotesDocument.
This item is totally decoupled from the field that created it. If you were to change the field in the form from text to number or move it around or make a names- field of it, the item in the existing documents would never change unless you open the documents and save them in frontend or use any LotusScript or Formula Code to recalculate the document in backend.
Very often items are added programmatically to documents to fulfill different purposes: Calculate values to be displayed in views, calculate values that are import for the workflow but not for the user, etc.
Complex applications often consist of a lot more items than there are fields in the several forms.
Back to your question: Removing an item from a document simply removes the value that was created by the field in the form. When reopening the document, the item will be repopulated, either by default value or whatever....
Usually you would use this to remove items that you no longer need (and probably already removed from the form).
As soon as you removed all references to a field / item everywhere in design and documents, you can finally get rid of it completely by compacting the database.
An item is distinct from a field in Notes. The form is purely a UI concept, the item is what the data is stored in.
Manipulating data in the backend can be used for a number of reasons. One such use case is the setting of a flag when a date on the form has expired.
Say you want a view showing all documents that have expired. Your rules dictate that documents are considered as "Expired" after 7 days. You could create a view with a formula that shows all document whose date is 7 days older than today:
SELECT Date < #Adjust(#Today; 0; 0; -7; 0; 0; 0);
This view will ALWAYS be out of date and will constantly be updated by the server as it re-evaluates #Today.
Now, a better way would be to create an agent that runs daily that sets an item on the document to indicate that it has expired e.g.
#SetField("Expired"; 1);
The view formula would then be
SELECT Expired = 1
The view would only need to update daily and you have a much faster view because of it.
RemoveItem is used to get rid of data no longer needed e.g. FaxNumber.
There are many use cases for RemoveItem. Here's one that comes up frequently.
You have a database and an agent that processes documents in that database. Every time it runs, the agent replaces the value of a bunch of items. There are a variety of error conditions that can cause it to abort processing a document early, but you're a smart programmer and you've accounted for that with on error traps. When you hit one, you log an error message, save your document, and then either abort your agent or go on to processing the next document.
But at this point, some of the items that the agent normally updates have values saved from this run, and some of them have values saved from a previous run. This might be bad. This might be confusing for someone who is looking at the item values and trying to figure out what's going on. This might even cause validation errors on the form.
So how do you avoid this? At the very beginning of your agent, you call a cleanup sub that finds and removes all the items that the agent is going to update. Now you have a clean slate, and if your agent hits that error condition, it can save whatever it can save without any concern about whether it is leaving things in an inconsistent state. Of course, in cases where you are doing this to avoid validation errors, your validation formulas will have to be smart enough to be checking #IsAvailable for dependent items, but that's a good practice anyhow.
I have one template from which I'm trying to refresh the design in my database.
However when I run "load design -f database.nsf" or select "Refresh design..." in the context menu in the Domino Designer it always skips the same design elements when updating.
There doesn't seem to be anything wrong with the settings on database level since some elements are updated properly. But I don't know of any other setting on element level than "Prohibit design refresh" that would result in this behavior. If I delete all forms in the database and refresh design again, only those elements that aren't skipped are added to the database.
I have tried creating new copies of database and template, compact, fixup, updall.
Ideas anyone?
UPDATE 1
Checked my elements (forms) access settings like Knut Herrman suggested, but this doesn't seem to be the issue either. The settings on the access tab is "All readers and above" and "All authors and above". (Would have posted picture, but sadly I don't have enough reputation)
UPDATE 2
Tried deleting all elements in the main database and refreshing after with the result that it skips the same elements as mentioned above.
UPDATE 3
I have uploaded a small example with a one template and one database, and only two forms for design elements, if someone wants to check it out. One of the forms is updated on Refresh, the other is not.
If I use Replace instead it works fine btw.
There is an issue with a Language setting that was applied to FormOne in your example database. I think the refresh is ignoring elements in the template that it does not think match your current language.
When I looked at the fields tab in the FormOne design properties, I saw an item called $BabelInfo. This item does not exist in FormTwo. My hunch was that this has something to do with Language settings, so I went looking for the Language settings in Domino Designer. I couldn't find them in the regular dialogs and editing panes! But when I looked at both forms in DXL¹ there was a Language property set to EN-gb for FormOne, and there was no Language setting for FormTwo.
Using the DXL editor, I removed the Language setting from FormOne. On first attempt, this had no effect, but then deleted FormOne from the database - which I presumed had inherited the Language setting, though I'm not sure I checked that. I did a refresh and it added FormOne to the database. Then I made another change to FormOne in the template and refreshed again, and FormOne in the database was correctly updated.
¹ I had to search around before I figured out how to get at the form data in DXL. A right click in the forms list in navigation pane brings up "Edit in DXL". That option is not available in the list of forms in the main pane.
Most likely, your missing design elements need a certain role.
Define those roles in your destination database's ACL and set the roles for you, your servers and relevant users.
It could also be the dates in the main and the template database, that somehow the element in the main db is newer.
Quick solution: delete the element in the main database and refresh it from the template.
This might seem rather obvious, but double-check that the "Prohibit design refresh or replace to modify" property is not selected in your design element properties, i.e. there should be no ticks in the column highlighted in the image below if you want all elements to refresh.
I suspect this may not be the solution, as you said Replace is working, but I thought I'd mention it.
Im making an Xpages application which needs to have server-side validation.
In my form, when a field is cleared and the form submitted - if there is another field which causes the validation to fail - it will be repopulated with the last successfully saved value in the document.
This is not what should happen. The field should stay blank until the page is either refreshed, or the user enters another value.
Does anyone have any idea about what is causing this to happen?
Thanks,
Paul
This depends on your execId and refreshId.
For what happens during partial refresh, read these blog posts, particularly part three http://www.intec.co.uk/tag/partial-refresh/.
If validation (or conversion) fails server-side, the server-side map of the XPage is not updated because the data is not deemed complete enough for server-side processing.
So the partial refresh skips to Render Response, which posts back what HTML should be displayed to the page. That includes values in fields - you're replacing HTML, so it has to.
If you're save button is refreshing the form area, you'll be replacing the HTML there, so overwriting the values entered by the user with the last valid values.
The recommended approach will depend on your page architecture and what you're saving. One is to move validation to the save() function, by which time the values will have been updated in the DominoDocument (the front-end wrapper for the Document on the server). Another is to only refresh the validation area and, if validation was successful, call context.reloadPage() or context.redirectToPage() to effectively skip the partial refresh.
Thanks for the help. As far as I can tell, it was simply due to the way the default converter included with xpages handles the object and/or string. Writing a java custom converter sorted everything out.
There is a lot of questions about binding data to forms. This is very simple. I have a form that uses several computed fields that pull data using an #DbLookup to populate the fields based on a pulldown menu the user selects. The problem is; none of the computed fields save any of the values into the form that it is bound to. The only data that saves on the form is the data that is manually selected (in the case of the pulldown menu) or manually entered. When I use an edit box and don't make it "Read Only" the data saves fine. Why is this so difficult?
Mark -
Couple approaches here I think... but let's walk though something.
Read Only on the edit box is preventing the save. It makes sense. XPages should not try to save something marked "read only".
As Steve says, you're better off here with a computed field. Set the values however and if their bound to the document then I think they will save fine.
Another approach is is to work with scoped variables. When you get your data points... you can put that into scoped variables like:
viewScope.put("myField", myValue)
then you're computed field could be bound to the viewScope variable "myValue".
however this will of course not save back to the document as it's not bound to the document. So what you do if you want that approach is in the document save event... you then use SSJS to assign the values to the doc then. something like:
document1.replaceItemValue("myfield", viewScope.get("myField");
Since xpages basically has the same document events as notes client. This may seem familiar to you.
Hope this helps.
Dave -
NotesIn9.com
Disclamer: I'm answering this from a plane after a trip to Las Vegas. So please factor that into the quality of my answer. :)
You will want to put the data you receive from the #DbLookup in an edit box field(s). A computed field is like a "Computed for display" field in traditional Notes development. You can choose whether to allow the user to change the values or not by the read-only property.
Also see this question if you want the values read-only which it sounds like you do: ReadOnly field in Xpage not submitted
As usual, Dave steered me to something that worked. Being in the larval stages of JavaScript experience, I'm sure there is a better way to do this. I'm just happy it works. Her is the code I put into the QuerySave event of my Xpage.
var cost1 = getComponent('ItemCost1').getValue();
var uom1 = getComponent('UOM1').getValue();
var Num1 = getComponent('ItemNum1').getValue();
var tot1 = getComponent('Total1').getValue();
docuent1.replaceItemValue("ItemCost_1", cost1),
document1.replaceItemValue("ItemUOM_1", uom1),
document1.replaceItemValue("ItemNum_1", Num1),
document1.replaceItemValue("CostTotal_1", tot1)
I have 30 iterations of this so it probably works kind of clunky but the operative word is WORKS. If anyone has a better way to get the same results, please post it so I can learn something. Thanks for everyone's help.
I'm not a Notes programmer, however, for my sins, have been working on some Notes features for an in-house project recently. I need to enable/disable editing of a field depending on circumstances. It seems to me to be a fairly standard feature, I need, but I can't find any information on how to do this anywhere.
In form setup (and other field's onchange) code, something like the following:
if some requirement = true then
textField.enable = true
else
textField.enable = false
end if
I've seen other places where there's a workaround of conditionally hiding paragraphs based on some code, having 2 paragraphs with opposite hiding conditions, one with an editable field, the other with a computed field. However, I don't know enough about Notes to see how this is implemented (I can see it done on other forms, but there seem to be some 'magic' steps within Notes which I either can't see or don't get).
[EDIT]
The reply from Kerr seems to be what I'm looking for, but I still can't find out where the InputEnabled property is located. Should have said in the initial question, I'm using Notes 7.0.3.
In fairness, it doesn't matter what the circumstances are for when to enable/disable the field, it's just some boolean condition that is set, in my case only on form loading so I don't even have to worry about this changing dynamically while the form is displayed.
I've got a few issues with Notes, my largest bugbear being that it's so tied so tightly to the Designer UI, which is utter shite. I can do this sort of thing programmatically in most GUI languages (C#, Java, Delphi, even VB), but I need to open property boxes in Notes and set them correctly.
This would be OK as an optional method, but forcing you to go this way means you can only work as well as the IDE lets you in this case, and the IDE here seems to actively work against you. You can't open multiple functions/scripts, you can't swap from one script to another without going back to the menus on the left, you can't easily search the codebase for occurrences of variables/fields (and believe me, this is a major failing for me because either Notes or the internal codebase in my case seems to make a lot of use of global variables!), you can only work with fields through the property boxes that get displayed, you can't edit code in Designer while debugging through the main Notes client.
While the Java side of the coding is better than LotusScript, it's still fairly crappy (why can't you debug INTO Java code?? Why do you need to re-import JAR files for each Java class, does each class have a different CLASSPATH???). Possibly this was improved in Notes 8, I hear it's based on Eclipse. Does anyone know whether this is true or not?
It would help to hear more specifics about the 'circumstances', but the most common way to handle this is to use a hide when formula on the field you want to enable/disable.
Technically you are not enabling or disabling the field, just hiding it, but usually that works just as well.
Since there are few events to work with in Notes, developers commonly use the document refresh as the 'event' to cause the field to hide or show.
Let's assume you have two fields called TriggerField and Subject. Say also you want to disable the Subject based on a value in the TriggerField. The easiest way to do so is to set the TriggerField as a Dialog List type and check the "Refresh fields on keyword change" option. This means when the value of the dialog list changes, the entire document will get refreshed.
Then in your hide when formula for the Subject field, you specify your criteria for when to show or hide that field. Anytime field values change, followed by a refresh of the document (i.e. form), that hide when formula will be re-evaluated.
There are other ways, depending on your circumstances, to solve this problem. If you want to let the user refresh the form themselves, put a button on the form that calls the #Command([ViewRefreshFields]) command. You can add any other formulas to that button before the refresh command if you want to make other changes to the form at the same time.
Another option is to make a certain field display-only. Then create a button that runs LotusScript to allow users to change that display-only field. In the script you can propmt the user for a value, set the display-only field, and then call for a document refresh.
In ND7 and up if you want to just disable the field for input, write an appropriate formula in the InputEnabled section of the field you want to disable.
So I have two fields one called Trigger, a checkbox with the value "On" and another Subject that is a text field. When Trigger is checked I want the value Subject to be enabled.
I simply put the following formula in the Input Enabled element of the field Subject:
Trigger = "On"
I also want this to be recalculated whenever the value of Trigger changes so I select the "Refresh fields on keyword change" option on the Trigger field.
If you're stuck in an older version you need to to hide paragraphs appropriately.