I need to create feature which will iterate through all subsites of site collection and add some sample content to each of them (sample content=new pages,images,documents,possibly some lists). There is solution that uses recursion to loop through sites (it can be found here).
So i'm asking:
Did any of you implemented something similar, maybe in different way?
What was the performance of such iteration?
I can't really say how many subsites can be present in site collection, since this feature should be used in more projects. But i guess the number of subsites shouldn't excess 100 or such.
That is a very common method of performing looping of sites and web parts.
Speed with 100 sub-sites will not be a problem. It is really quick, if you do alot of processing that can slow it down.
The one thing to watch is the disposal of items if you leave the open or don't close you can suck all the memory from the WFE, especially if alot of users reload the page at the same time.
See http://www.sharepointnutsandbolts.com/2008/06/disposing-sharepoint-objects-what-they.html and http://blogs.msdn.com/rogerla/archive/2008/02/12/sharepoint-2007-and-wss-3-0-dispose-patterns-by-example.aspx for examples they also have the disposal tool at http://blogs.msdn.com/sharepoint/archive/2008/11/12/announcing-spdisposecheck-tool-for-sharepoint-developers.aspx
You can look at the answer I gave to this question. I think I've used the correct dispose patterns for that piece of code.
If you need to do a read-only loop through a big structure, here's a cool, yet a bit untraditional, way of doing it:
http://hristopavlov.wordpress.com/2008/10/20/a-very-fast-method-to-get-the-site-collections-web-structure/
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 got quadtrees working on a swingers site I have been building. But I wondered what other equally powerful approaches there would be to searching based on location.
I havn't bee able to find much about this.
Have look at the bottom of the Wikipedia Quadtree page. Other commonly used multi-dimensional indexes are kd-Trees and R-Trees. There are also more specialized depending on what you need to do.
R*Trees (RStarTree) and kdb-Trees are, for example, good for aligning them with a page size so they can be efficiently stored on disk.
We have this page in SharePoint that list all the sites, the person who manages that site, their contact info, and the last modified date.
Currently, we are using a custom webpart that crawls through the sites and reads through the metadata, and then it displays all these in a list.
Opening this page takes about 10+ seconds.
We're looking at ways to cut this time to less than 3 seconds.
I'm thinking about some sort of timer job that caches the page, say every half hour, and when the page is requested, simply display the cached version. The data in the page itself doesn't change that often so caching isn't really a big issue. Is this idea feasible? I'm fairly new in SharePoint so what would be the steps to implement this?
Or if there are any other options/suggestions on how to reduce the load time, I'm all ears.
here are some approaches that might work for you.
Extend your existing Webpart with a cache. So the first User who visit the Site will wait as long as with the existing Solution. But he will fill the cache, so every other call of the Site will be much faster
http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.webpartpages.webpart.partcachewrite(v=office.15).aspx
Create a Timer-Job that fill up da extra SharePoint- List with the fields you need. So you render your Webpart using this data. To fetch the needed data from the List will be much faster than iterating some SPWeb or SPSite Objects.
A lot of data already can be fetched from the Search-Service, and you can extend the Attributes the search engine will crawl. Once the search attributes are extended you can create a search driven Webpart
http://technet.microsoft.com/de-de/library/jj679900(v=office.15).aspx
Each of this Solutions should work at SP 2007/10/13
If you need a quick-win than mybee Solution 1 is the best for you.
Regards
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.
I'm about to launch a multi-domain affiliate sites which have one thing in common which is content. Reading about the problem with duplicate content and Google I'm a little worried that the parent domain or sub sites could get banned from the search engine for duplicated content.
If I have 100 sites with similar look and feel and basically same content with some minor element changes, how will I go on preventing banning, indexing these correctly?
Should I should just prevent sub-sites from been indexed completely with robots?
If so how will people be able to find their site... I actually think the parent is the one that should only be indexed to avoid, but will love to her other expert thoughts.
Google have recently released an update that will allow you to include a link tag in the head of pages that are using duplicated content that point to the original version, they're called canonical links and they exist for the exact reason you mention, to be able to use duplicated content without penalisation
For more information look here..
http://googlewebmastercentral.blogspot.com/2009/02/specify-your-canonical.html
This doesn't mean that your sites with duplicated content will be ranked well for the duplicated content but it does mean the original is "protected". For decent ranking in the duplicated sites you will need to provide unique content
If I have 100 sites with similar look
and feel and basically same content
with some minor element changes, how
will I go on preventing banning,
indexing these correctly?
Unfortunately for you, this is exactly what Google downgrades in its search listings, to make search results more relevant, and less rigged / gamed.
Fortunately for us (i.e. users of Google), their techniques generally work.
If you want 100s of sites, to be properly ranked, you'll need to make sure they each have unique content.
You won't get banned straight away. You will have to be reported by a person.
I would suggest launching with the duplicate content and then iterating over it in time, creating unique content that is dispersed across your network. This will ensure that not all sites are spammy copies of each other and will result in Google picking up the content as fresh.
I would say go ahead with it, but try to work in as much unique content as possible, especially where it matters most (page titles, headings, etc).
Even if the sites did get banned (more likely they would just have results omitted, but it is certainly possible they would be banned in your situation) you're now just at basicly the same spot you would have been if you decided to "noindex" all the sites.