I have a classic lotus notes form with 1800 fields and 7 tab,
Will the performance improvement if i split the form in 7 different form and then bind to the xpages
or
if i directly bind the form to the xpages will there be any performance impact?
thanks
That's a "try that with your RDBMS" type of situation.
Splitting forms will not help you, XPages doesn't care too much about how many data sources are used if the number of bindings is high (and you have a ratio of still > 200 for many forms) --- and you actually don't bind to a form, you bind to a document. The form is only a "design time convenience".
Making some wild guesses I would presume that a lot of the fields are repeating fields (like LineItem_1 LineItem_2 LineItem_3 ) instead of multi-value fields.
Moving forward you need to make a basic choice:
Is your data format fixed since all views, reports, import/export routines etc. rely on them .or. can you refactor the data model (based on your question I would presume the former).
If it is fixed I would look to encapsulate the document into a managed bean that provides collections of data for the repeating sets of fields and repeat controls to show the number of entries you actually need (The classic way would be to have different hide whens in every cell of the table hosting the fields). This way you have much less bindings to look after.
A very basic idea how to have a dynamic table can be found in Excercise 23 of the IBM XPages tutorial
Disclaimer: Tim Clark and I wrote that.
You also might consider using only that parts of the document the specific user needs that moment.
For this kind of situation, As of my concern, You have a form with seven tabs and 1800 fields. But it is too complex. But however we split a form into seven, each form will have 260 fields. now also code will become complex.
But my suggestion is that you can dynamically change the binding data in xpages. If you feel very complex to redesign the form then you follow the above idea. Otherwise change the design and make a nice look-up in xpages.
Related
Sorry not a coding question, not sure if I should be posting it here.
I struggle with the concept of what is 'large' in Notes nsf application design elements as opposed to the amount of data or records stored. For example it is stated that we shouldn't have too many views, but 'too many' does not give any scale whatsoever, is it 10,50,100,500 before it 'slows down'. I realise it also based on the view design but some idea of 'too many' would be beneficial. In this instance data and design elements are in the same nsf.
Is there a recommendation regarding number of elements such as XPages, Custom Controls, Managed Beans, Java Classes etc. What would be deemed excessive? In this instance I have data and logic in separate nsfs.
Any guidance would be greatly appreciated.
Thanks
There is a limit on the number of design elements. But unless you're importing a whole JavaScript framework into an NSF, uou're not likely to hit it.
As has been mentioned, view performance is dependent on many factors. 500 decently designed views are fine. 50 badly performing views can be bad. Lots of resorts on columns impacts the number of indexes that need to be created and managed. Using #Today or #Now in a view selection formula or column formula will be a big problem. Having lots of documents that rarely change, smaller numbers of documents that are updated every 30 seconds, lots of users regularly updating - these will all be impacts on performance.
Performance in code will also impact and XPages Toolbox or agent profiling will give an idea. DocumentCollection.count() is slow, but sometimes is needed. NoteCollections may be quicker. There are various blog posts covering this.
A managed bean that has a Map that grows and grows will impact Java memory.
But there are always performance enhancements being made on the server side. gRPC in Domino 10 will be extremely performant. So always try to be on a recent version and keep up to date with sessions at conferences etc so you know what TCO improvements are being made.
The bottom line is without an intimate understanding of your architecture and code, no one will be able to give you a definitive answer.
I've resolved this problem in a complicated way and now I'd be delighted to see if there's a simpler solution.
Suppose that we have two custom entities, Alpha and Beta, each of which has a custom field called reference. If I place two lookups on a form, one for each of the custom entities, all's dandy as long as I don't require the lookup processes to depend on each other.
Now, what if I pick Alpha instance (call it a) first and then only want to see those Beta instances in the search box that share their owner with the selected a? That's easy, right? You just customize the filtration of the field.
But what if I want the selection of Beta instance to be predicated on the custom reference field?
Do I really have to declare a dynamical view to cheat myself around this part? It's so inconvenient and cumbersome...
You've done it the only way I was aware it could be done.
We can only hope it might be different in CRM 2013 i guess.
I'm creating a Book store in Magento and am having trouble figuring out the best way to handle the Authors of a Book (which would be the product).
What I currently have is an Attribute called "authors" which is multi-select and a thousand [test] values. It's still manageable but does get a little slow when editing a product. Also, when adding an option/value to the authors attribute itself, a huge list is rendered in the HTML making this an inefficient solution.
Is there another approach I should take?
Is it possible to create an Author object (entity type?) which is associated to a product through a join table? If yes, can someone give me an explanation about how that is done or point me to some good documentation?
If I'd take the Author object approach, could that still be used in the layered navigation?
How would I show the list of all books for a single author?
Thanks in advance!
PS: I am aware of extensions like Improved Navigation but AFAIK it adds something like attributes to attributes themselves which is not what I'm looking for.
For Googlers: The same would apply for Artists of a music site or manufacturers.
If you create an author entity type, you'll just increase your work trying to add it to layered navigation, and I don't see a reason why it would be faster.
Your approach seems the best fit to the problem, given the way Magento is set up. How are you going to display 1,000 (which presumably pales in comparison to the actual list) authors in layered navigation?
Depending on the requirements, you could go the route of denormalizing the field and accepting text for it. That would still allow you to display it, search based on it, etc, but would eliminate the need to render every possible artist to manipulate the list. You could add a little code around selecting the proper artist (basically add an AJAX autocomplete to the backend field) to minimize typos as well.
Alternatively, you could write a simple utility to add a new artist to the system without some of the overhead of Magento's loading the list. To be honest, though, it seems that the lag that this has the potential to create on the frontend will probably outweigh the backend trouble.
Hope that helps!
Thanks,
Joe
I'm working on a pretty basic web app (not much more than CRUD stuff). However, the requirements call for a bunch of data to be displayed with each item in the search results - IDs, dates, email addresses, long descriptions... too much to fit neatly into a simple grid, and too dissimilar to make them flow together (like the natural language example from this article.)
Is there a design pattern for attractively displaying many descriptive fields with each search result?
(Please don't tell me to just remove some fields from the results; that's not an option for this project.)
Obviously there are many ways you can handle this, and to a degree it's a factor of your information design abilities and preferences.
Natural Data Groupings
What I would do is try to organize your data into a small number of "buckets." You state that the data are too dissimilar to be arranged into a sentence, but it's likely you can create a few logical groups. Since we can't see all your data, I'll guess that you have information about a person (email, name, ID?), about some sort of event (dates? type?), or maybe about some kind of object related to the person (orders? classes?). Whatever they are, some of the data will be more closely related to each other than others.
Designing in Chunks
Take each loose "bucket" and design a kind of "plate" -- a grouping just for the information in that bucket. The design problem within this constrained chunk is easier to tackle: maybe it's a little table-like layout, maybe it's something non-tabular, like the stackoverflow user "nameplate". Maybe long textual data have their own plates, or maybe they're grouped into a single plate, but with a preview/detail click-for-more arrangement.
Using a Grid
Now that you have a small number of "plates," go back to a grid-like approach for your overall search result row design. Arrange the plates as units within the row, and be sure to keep them aligned. Following an overall grid (HTML table or otherwise) for the plates will avoid an "information soup" problem. You'll have clean columns that scan well, and a readable, natural information hierarchy. The natural language example you cite would indeed be difficult to parse if it were one of many rows displayed in a search results grid.
Consistency
Be sure to use a common "design vocabulary" when you're working on the chunks -- consistent styling of labels, consistent spacing... so when everything's displayed, despite the bulk of information, it all feels like it's part of the same family.
It's an interesting design exercise. Many comps, lots of iteration, and some brainstorming should get you where you need to be.
It probably depends on the content you're displaying. Look at the StackOverflow layout for this question. It has Votes, Title, Description, Tags, Author, etc. The content wouldn't work well in a grid for sure, nor does it flow nicely on it's own.
I think it's time to get creative ;)
No one ever thinks about what this is going to look like on their screen, do they?
One thing you can do is truncate the displayed text, and then display the expanded version in a tooltip on hover, or after the user clicks on it.
For example, display only the two-letter state abbreviation but show the full state name on hover.
Or, to save even more space, only display the state abbreviation, and put the entire address in the tooltip.
For long descriptions, you can display only the first few characters, followed by an ellipsis or the word "More". Then, show the full text either on hover or on click.
One disadvantage of the hover approach is that you can't sort the column on that text. There's nothing for the user to click to request the sort.
My web applications have pages that display many static fields.
I know that poor layout invariably leads to information overload and poor readability.
My Question:
Are there any best-practices or heuristics for laying out a screen that contains many static fields?
Ordinarily, I would reference Bill Scott and Theresa Neil's excellent book, but I can't seem to find any guidance for this issue.
Here are some guidelines that I'm inclined to follow:
Group related fields.
Position the major (or parent) fields towards the top and the left. Position the minor (or child) fields towards the bottom and right.
Don't feel obliged to fill every pixel. Consider white space if it will improve readability.
Favor progressive disclosure wherever possible.
Consider an accordion control.
Perhaps a Details on Demand approach would work well. Ask yourself which data are absolutely and immediately relevant to the user and group those, while hiding the other data. You can always provide an 'Expand' link or control that would allow a user to view the details if desired.
(It's good to see that you're looking at interface design patterns. They are often overlooked!)
I work on HR software and have faced this problem many times. One thing that we keep seeing in feedback when we introduce collapse controls or any progressive disclosure pattern really is that our users don't like the way those types of "web 2.0" (their words lol) pages don't print out. So just a reminder if your user base still insists on printing large pages of data include a print media stylesheet.
Depending on how large your set of data is I'd seriously consider a some search functionality or a sorting mechanism. Many times when the data set is large different users have different priorities and allowing customization is the only way to satisfy a wide audience.
I think you pretty much answered your own question, especially the grouping of important fields tied to progressive disclosure.