I have a news page with hundreds of news items so we are applying pagination on this page and displaying 20 items per page – For this we applying the filter in broker query as below -

query.setResultFilter(new PagingFilter(minitems,pageSize));

Now after executing below query we are getting the news components URIs -

String [] comURIs = query.executeQuery();

Now in these components there are few components which do not have any component presentation with the component template used on this concerned page. In other words below code gives some NULL component presentations (cp). -

for (int i =0; i < comURIs.length; i++)
  ComponentPresentation cp = cpf.getComponentPresentation(comURIs[i], strCTuri);        

Now below is the issue due to these NULL component presentations -

"When API code executes for the pagination index 1, there are some NULL CP (suppose 5 out of total 20) available and we are excluding these NULL CPs from the returned result set. As a result this page with pagination index 1 display only 15 items and page with pagination index 2 and onward displaying all 20 items”

I need consistency in item per page and also “item per page” is getting set by the Editors. How to deal with this issue, please suggest.

3 Answers 3


As far as I know, best way to use a DCP is

  • Query the broker based on your CT which is specific to a page
  • If the DCP used on different pages, you make sure to publish a flag entry (By which you can identify the page) on the CUSTOM METADATA table
    • Based on the CUSTOM METADATA entry, you can query the broker to get the results specific to your page

On top of that, Cache Channel Services will be running on the server and which returns cached results


I think @Siva hinted on this in his answer:

Query the broker based on your CT which is specific to a page

To clarify, add an ItemTemplateCriteria into your query. This should ensure that the DCPs for a given component exist, hence you won't be getting NULLs back.


I asked a similar question on the Stack Overflow site a while ago (before the Tridion Stack Exchange was born): Tridion pagination - getting the total number of results

Mihai suggested in his answer that you could get all of the DCPs (as you are above) and then cache the results.

It might be that there is no DCP for a given Component, therefore you need to read all DCPs first in order to know the exact number of items you want to paginate for. Obviously this will defeat the whole purpose of pagination. You might alleviate this performance drop with running the query once, then cache it for a while.

However, as he then points out, this caching becomes slightly more complicated if each website visitor can query for different terms (rather than the query being fixed by the application).

The short answer is no, I don't think that there is a way to do this in your API call. You will probably need to handle this in your .NET / Java code.


It appears that this can be done using the ItemTemplateCriteria constraint. Please see Nickoli's answer for details.

  • I would not want to remove PagingFilter benefits as down the line count of news items can be in thousands and my problem is to display 20 items at each page . But in case of 15 + 5 (NULL CP). it displays 15 item on a page. I can not go with the complex implementation here due to being a support responsibility on a live site.
    – user584
    Jan 16, 2014 at 13:36
  • @user584 I agree. It is a similar problem to that which I faced. Unfortunately, there is no way to ensure that all Components returned by your original query actually have a Dynamic Component Presentation (DCP), using the Tridion API call. If the problem is just that the Component needs to be re-published, then you could log (possibly with email notification) this and make sure that the Component gets re-published. Jan 16, 2014 at 13:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.