If any document remains opened for some time (example 10 mins or more) in edit mode and then tried to save after that then save is discarded and document is just refreshing and opened in read mode. How to prevent this as it causes user to loss the entered data.
It sounds like your page is removed from the list of stored pages. XPages stores a limited number of pages in either memory or on disk depending on how server page persistence is set up for your application. So my guess is that you are opening other pages from the application in separate browser tabs.
Once you hit the limit pages are removed from the list in order of appearence. This means that XPages has no knowledge of the component tree for the particular page which is no longer stored. This explains why your changes are 'discarded' and why the page is reloaded.
The default number of stored pages is only 4 in 8.5.x and 16 in 9.0.x.
My recommendation is that you increase this number by changing the server page persistence settings on the Persistence tab of Xsp Properties.
You should also be aware of the option to mark specific XPages to not store state by setting the property viewState to "nostate" on the xp:view component. This is useful for readonly pages and for 'xagents' that do not need to store state.
Notice: the keepSessionAlive control will not help here as you need to 'keep the component tree alive' - not the session.
I guess you may have hit a "session timeout".
What I will suggest that you do is to set a long application timeout and a short session timeout - and use a "keep alive" custom control to make sure that the session will not time out while you are editing it.
I have tried to explain some of these features in a blog article that may give you a better overview ;-)
/John
Related
I have a custom list tracking idea submissions (think virtual suggestion box) where I am attempting to customize the DispForm.aspx so that users will not see fields that are not directly relevant to viewing the submission.
I am making a copy of the original DispForm.aspx and renaming to i_DispForm_mod.aspx and then changing the settings of the list to use this as the display form.
Problem is, once I modify the display form settings, it takes over the whole ball of wax. I can no longer access EditForm.aspx. Clicking on "Edit" gets you the display form.
Creating the URL to the edit page manually takes you to the display page. Creating a new item works as normal.
For some reason, SP is deciding to redirect all requests for EditForm.aspx to the display form. Properties for the list supporting files are set to all the appropriate pages - but SP is ignoring that in favor of serving up the display form. WTF?
I have no idea how to fix this. This is my second go-round with this after abandoning the first list created when I first got this behaviour.
Oh and just to add additional fun, the behaviour persists after restoring to original DispForm.aspx and resetting list supporting file properties appropriately.
Absent solutions I may have to mark DispForm.aspx as radioactive, do not touch and abandon my design as unattainable.
I cannot find anything similar being documented anywhere on the web.
Is there a way to have user selected records remain selected as the pages are changed in the view? Currently, when changing pages in the view, the selection is lost.
For example, the user is looking at the Accounts entity, and wishes to select a few records from the first page of results and other records from subsequent pages.
I have explained that this is standard behaviour and that they should further filter their results but they are insisting that I try to find a solution.
There isn't a supported solution to your problem other than writing custom web-resource pages that will do exactly what you need.
I'm sure you've already told them to set their "records per page" to 250 in their Preferences.
In CRM 4.0, I once figured out where this "records per page" setting is stored in the database and I was able to change it to 5000 directly in the database. It did work (I think I had to iisreset as well), but it is obviously unsupported and could cause massive performance issues.
In a production application that I have developed sometimes I get an error saying .getDocument() is null. I have added checks in my code that traps an error if this happens. And the strange thing is that the XSPDocument seams to be OK.
Any other ideas how to debug the cause of this?
========================================================
Edit
The lower parts of the application is a simple database, create an assignment it gets status new
change the status to ongoing thru a button. Add information in text, date and numberfields, no Richtext, no attachments.
The user can switch to another xpage to send this document is an pdf attachment in an email.
The user can save the document as a draft
When they are done the click on an approve button and this button will set the status to approved. Save the document and send it as an pdf to an email adress
The problem ocurrs both on the Save button and on the approve button.
.getDocument from the xsp document is null the xspdocument.getNoteID return an ID
I can do replaceitemvalue on the xsp document.
It never happens on new documents only existing what I have seen
It feels like the comment from David that the backend doc is dropped/recycled
we experienced the same getDocument() problem recently. Finally we found a root cause: two different XPages were loaded simultaneously via iFrames. One of those XPages produced run-time error randomly, in 25% of cases. A sort of conflict in JSF model in context of single session.
solution: viewState="nostate"
not sure if it helps in your case, but this option resolved a lot of problems in our applications. It was introduced in 8.5.3. And it should be especially useful for so called XAgents.
Hard to give a hint without knowing more about everything else, but I remember having seen this as well. Just a few ideas:
Is XSPDocument.getNoteID() pointing to a valid Document if this happens?
Is it maybe pointing to a different doc than what you expected?
Could there be some kind of dynamic change of datasources going on?
Maybe some kind of timeout so that the server all of a sudden forgot who you are (in rare cases this happens to me)?
Lothar/edcom
It would be helpful to have a few more details. I assume that the document has previously been saved and it's not a new note?
You're not trying to put the actual document object inside a scoped variable are you? That would be bad as that would be pretty toxic. Without knowing more I would think this could be the case. The backend document has been garbage collected.
When using the Ext.Lib Name Picker control connected to the NAB, the default is to view the first 50 entries from selected view (depending on whether groups/Persons is selected in property).
But there are no scroll/paging buttons on the dialog.
If I want to pick an entry from the NABPicker and the entry is after the first 50 I must use the Search button to find it.
Is this working as designed or a feature not yet added?
/Mike
You might be interested in using the viewpicklist control from openntf instead, link
It is very felxable, just set it to use the names.nsf and whichever view you need.
As far as I know this is working as designed. The server only returns a set number of entries so that the amount of data transfered when opening the Name Picker dialog box is kept nice and small, this way the dialog box opens faster.
You can increase the number of entries returned by increasing the maximum limits in the server document and internet site document and then increasing the maxRowCount attribute on the picker but you will seriously affect the performance of your application and it is not recommended.
Hopefully in a future release of the control they will add some sort of ajax based scroll similar to the inbox scroll in iNotes.
Mike:
I think the answer is "both". Working as designed and feature not added yet...
The Ext Lib is a open source initiative designed to support the simplistic Discussion, Team Room, and Document Library applications. The designers have limited experience with more complex applications and clearly limited exposure to large address books in their development arena.
The NAB pickers are a source a major disapointment to those of us trying to build larger scale applications. Perhaps at some point it will become a usable component but is is only marginally usable at this point.
/Newbs
I need to count the page impressions of every page on a TYPO3 site into the db.
So I think I need an extension which is called on every page impression and increase a column 'impressions' in the db of the specific page.
I'm new to typo3 and new to extension development as well. Is there a way to include an extbase-extension on every page so some php-script get called?
(Update)
I want to add more information:
I don't need a counter which counts all PIs. The counter needs to be page-related. So it make sense to extend the pages-table from Typo3. Another need is that the extension should be done with extbase.
I'm new to typo3 and new to extension development as well. Is there a way to include an extbase-extension on every page so some php-script get called?
Once your plugin is configured you can include it with page.1234 < plugin.tx_yourextension_pi1 on any page. 1234 determines the position on your page.
The script should be USER_INT, so it's not being cached (mind you, this will cost loads of performance as previously stated by #norwebian)
As you don't want to output anything, make sure the controller stays empty as well.
Did you do a quick search in the extension repository? Trying a search for "page counter" reveals four relevant extensions.
"Sys_stat" is the closest thing to an "official" solution, it is really just enabling a few settings already existent. It has been reported to fill up the database with too much data, though.
"Generic Visitor Counter" would be my favourite, I believe (if I was going for a page counter at all), it is recently updated and seems simple enough.
You should really consider a proper stats extension, though. Both ics_awstats and ke_stats have been in my toolset.
YMMV. Be aware that if your site is popular, stats gathering quickly gets out of hand. On the other hand, if you go for a simple counter, including uncached extensions will cost performance.
I am not sure if I really understood what you want and need. After all, page impressions are not the same as page views. I wouldn't know the difference "onpage" right now though. So am I right in assuming that you mean page views?
If yes: I would take the following approach:
A separate, autonomous extension with a JavaScript for asynchronous calling of an API and a table for storing page views / page impressions.
Each page globally binds a JavaScript that initializes itself.
Once the DOM is ready, it sends a call to an AJAX API endpoint with the URL of the page as a parameter.
The endpoint takes only the URL.
For each unique URL, a record including counter is created or updated.
Extending the table for the pages doesn't make sense to me. What are you doing with a website that consists of news overviews, news details, press and blog sections, a dealer search and a store with product pages?
I would keep the statistics table standalone.
If you expand the table a bit and add date and time - no simple increment of hits - you can even identify the hottest pages of the week, the month, etc.
--
My approach won't increase/delay page load time much, if at all, and will have little noticeable impact even on heavily requested websites.
With the AJAX endpoint, it's then up to you how you deploy it and how much of the CMS framework you want to load.