I have a lot of fields on a form. Not exactly sure how many but it has to be close to 100, if not over.
I have a change event of one field doing a partial refresh of a computed field with the following formula.
return document1.getItemValueString("txtCustomScore");
txtCustomScore is the field that has the event.
It takes 3-4 seconds to update this field. Are all of those other field somehow affecting how long it takes to refresh this field? It is taking 3-4 seconds.
I even tried getValue instead of getItemValueString. As suggested in this thread:
Setting a document field with replaceItemValue from a rich text control?
But it still takes 3-4 seconds to update the computed field.
Is there anyway to fix this other than eliminating fields from the form?
Yes it does. Even for a partial refresh all component values get evaluated and the server side result tree is built. As Tommy suggested, partial execution mode might be your answer
I strongly encourage you to watch the XPages Masterclass Video Series 1 (See: http://tonymcguckin.wordpress.com/2013/04/22/xpages-masterclass-series-1/).
From this you will then be able to introspect the XPages Request Processing Lifecycle phases and Profile your application. This will uncover the exact reasons behind the processing cost.
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 would like to conditionally run a custom converter. I have an XPages that handles editing and new data on the same page. The user selected a radio button to edit or create a new item.
The input fields are shared between these two functions. Upon page load I do not know what the user will do so I cannot use the "Loaded" property of the converter.
I need to format the data in this format '$900,000'. Note that there is no cents in my required format.
The built in converter for numbers or currency fails me because no matter what I do, it always add the cents. I assume that this is a bug in XPages. It doesn't matter if I say "Integer Only" or set the Maximum Fraction Digits to zero. The cents do not go away.
I have a custom converter that works fine for me, but only works when it is recalculated once, and fails when recalculated. I have tried setting the partial refresh updates to "Do not validate or update data" and this works, but breaks other parts of the page where I needs the updates to be enabled.
This application is soon to be deployed and it is too late for me to re-engineer the whole page structure to solve this issue -- too many moving parts. All I need to do to please the testers it to get rid of the cents (xxxx.00) that are added to the value, and still have everything else work.
My problem is singular, but my questions are tri-fold. How can I:
Get the built-in currency converter to remove cents the way it should? Or
Get the custom converter to be enabled ONLY based on a user-entered value? Or
Help me think of a different approach to solving this issue?
Steve, I have really fought a battle with converters as another problem is that they are all run prior to validation - and as such error messages are not necessarily shown in sequential order.
Therefore, I ended up using validators (also for the work of the converters). And on top of that I use "binding" of the components (not the values) to easily access other fields on the same page. This allows for conditional checks/logic. If you have not tried component binding, then there is a great introduction by Tim Tripcony.
/John
A couple ways to do this, One would be to do the conditionally checking of user in the custom converter. Another approach would be to use a PhaseListener and in RenderResponse Phase get the Component and set the Converter on the component to null when you don't need it on the component. I typically don't use converter though if its just the display of the number, just if I actually need the value converted. I would use something like a display Mask I've recently used a jquery plugin called maskMoney that worked well for a similar problem.
I assume your converter is on an editable field, because otherwise it won't fail on submitting data.
The problem sounds to be timing. The converter has to run during page load, in order to convert the Number value stored in the database to a String value required by the browser. So some default needs to be set, which presumably is to connect it.
If you're then wanting to change the display option based on input, you've got to do a partial refresh after the input, in order to recalculated whether cents should appear.
Once the inputted value is passed back from the browser to the underlying component tree, you can calculate accordingly - providing your converter knows what to interact with. The process dugint he partial refresh is to restore the component tree, apply the request values (store the String value from the browser into the submittedValue property of each component), process any converters or validators, then update the component tree. So when the converter runs, the radio button's value property isn't set, so it works on the last refresh's setting - the default.
By choosing "Do not validate or update data" then you're saying don't bother writing back any inputted entries from the browser into the component tree. So I'm sure you can that means the converter will know nothing about what's been input.
John's suggestion on binding is a good one, but remember you'll be needing the submittedValue property of the relevant component. For a radio button, I'm not 100% sure what that will be, but you should be able to print it out.
The mask approach may work. Someone else used that recently to make integers work right.
The other option is to look at the Extension Library's Dojo Number Validation Text Box, which has a javaType property and a more flexible set of converters. That may well allow you to avoid cents. If it does and you don't want the Dojo look and feel, it's converter should give some ideas on what your converter needs to do to remove cents.
I could not get any of the answers above to work, so I cloned the text box. I made one show up for "Edit", and one show up for "New". I kept everything the same, but only added the custom converter to the one that shows for "Edit".
Thanks again for all your help. The XPages community rocks!
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.
I have two instances of the same ViewController class accessed in different tab items. Both use the same entity, but with a different predicate. One displays all the items, while the other displays a subset based on its predicate.
The problem occurs when I delete an object from the "All" list. It updates immediately, but when I switch over to the other tab, the object is still there, even after going back and forth in the views. Only after a period of time, around 5 to 10 seconds, does the deletion get reflected in the other view.
The ViewController class use a FetchedResultsController.
Any ideas what the cause is and how to get the results to immediate appear?
Just put a reloadData into viewWillAppear. You can also catch this when the tab bar's selected index changes.
Apparently, there is no solution. There is no way to update UIManagedDocument manually.
This guy came to the same conclusion:
Core Data managed object does not see related objects until restart Simulator
So the solution is to use the default master-detail template and to stop using UIManagedDocument. Wish there was some documentation on this, would have saved me a day of my life.
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.