Hi all,
I have had a design request that has been puzzling me for some time now, so thought I would throw it out there to get some expert opinions.
The requirement is to have a main document, which then dislpays details of any number of child documents (which can be one of 2 different forms) categorised by a common field, and have the look and feel of an embedded view.
I have ruled out certain options to manage this for the following reasons:-
Embedded View - the categorised row neesd information displayed for 5 or 6 seperate fields, lining up in the view to common fields to the underlying documents.
Large Table with hide whens - works OK when there are around 20 records, but the requirement is for the capacity for more than this - then speed becomes prohibitive for this approach.
I eventually settled on creating each record as the document opened with a form that looked like the row of the table required, then using renderToRTItem to dislpay these in Rich Text fields. This works fine until I hit around 150 records, then I get an error that Notes has hit its limit of Memeory Segments.
The other complication here is that each row has 2 or 3 hotspots attached!
Any other ideas to try?
Subject: Huge Table - best approach
Jonno,
Inherently, it’s always going to be a tough time displaying gobs of data in a useful way. Case closed.
In your situation, I have sometimes found that I can make a table that displays just n rows and have clickables to switch which rows are being displayed. Since all the data is being stored locally in the document (right?) it’s super fast so users don’t feel that it’s a big hassle.
2c,
raphael
Subject: RE: Huge Table - best approach
Why not use an agent to print the data from each child doc out to the main doc?
Hughster Rooster
“When in doubt, always assume the Animal doesn’t enjoy being tortured.” - Ricky Gervais
Subject: Huge Table - best approach
No clue if this would work…
Could you use dbLookups to build a set of values that you could then concatenate together and display so they look like an ordered table? You might need to try permutated string addition (*+ instead of just +). I have a dim memory that I did something like this a while back but I don’t recall if I was putting together a string from multiple doc types.
Given my DbLookup troubles the last few days, you’ll want to take this suggestion with a grain of sand (or maybe a whole truckload…).
Doug
Subject: What’s wrong with an embedded view?
I have ruled out certain options to manage this for the following reasons:-
Embedded View - the categorised row neesd information displayed for 5 or 6 seperate fields, lining up in the view to common fields to the underlying documents.
Create a view of documents categorised on the common key with a second column that displays the ‘viewtext’ field of the documents. Whatevever you need to display for that type of document is contained field of HTML. Use css to handle styling.
or have I misunderstood?