Hi,
I have to load around 5000 documents in a web page…
Which method will be the fastest? View, agent or reading an XML?
If anybody can help…
SP
Subject: SHow 5000 documents on web
Depending on how volatile your data is, you may be able to prebuild your output. I recently did a once a day report that summarized 7,000+ documents. I did this by running a nightly agent to build the HTML report directly into a completed Notes document. A view sorted these so that the most recent was placed at the top. The report link provided a URL directly into this.
Stephen
Subject: RE: SHow 5000 documents on web
Pls can u be more specific…
Subject: RE: SHow 5000 documents on web
Initially there was an issue processing 7000+ documents on demand via a WebQueryOpen type agent. The agent would take a long time, and based on the server’s configuration, other web agents would not run until this agent finished. This created a condition where pages would lock up while the agent ran for some minutes. Our users were interested in a daily report more than a real time report, so we mitigated this issue by scheduling a night time server side agent that processed the data that had been taking place via a user invoked web agent. The schedule agent would take on the job of stuffing the report data as HTML into a Notes document/Rich Text field. Then users would simply open this completed document with all the HTML already generated by the night time agent. Application URLs and views hosting the report were created that always sent the user to the most recent report. This eliminated the long delay incurred if building the report on demand via an agent url.
Stephen
Subject: SHow 5000 documents on web
I have had good results displaying the xml for the documents in a view, then reading the view-xml into an xml-data-island on the HTML page, then using Javascript in “Next” “Previous” buttons to read the xml-values into a dynamically generated table.
The performance (on extremely large numbers of docs - as many as 50,000 docs) was surprisingly good.
I did this so as to avoid round-trips to the server i.e. fetching the next/previous page of view data.