I understand it was difficult to get Rhythmyx to do paging of, for instance, auto-indexes, in version 5.x.
Is there any information on doing this in version 6.5?
For instance, if I have a page with an auto-index of news items and I want to display 10 items per page and there are 25 items I essentially want to publish that same page out 3 times, for pages 1, 2 and 3 of the results - and link them together using the page links eg “<< < 1 2 3 > >>” where “<<”
goes to the first page, “<” goes to the previous page, “>” goes to the next page, “>>” goes to the last page, and 1,2 and 3 go to the relevant page.
I’m wondering if an approach would be to use hidden divs and some Velocity cleverness.
I’m also going to have to do something like this for content items which are going to have more than one “chapter” in a new implementation, with each chapter being a child field with a title and body.
Pagination is a bit more complex than just some Velocity macros and hidden <div> tags.
The best approach is to publish multiple pages, and provide a scheme for generating locations (and urls) that allows you to link between the pages.
We’ve done this at a number of different customers, and we have some “toolkit” level code that provides a mechanism for breaking up the pages and for generating the location schemes.
However, this isn’t really documented in a way such that customers can install it. Depending on your specific requirements, you may have to write some additional binding functions (in Java). For simple cases, you might be able to get away with the ones we’ve already written. The case you mention (multiple child rows) is not one of these simple cases, however.
This will be included in a future release of the product (and it will be documented in that release).
We do have some experienced consultants in the UK office who have done this a time or two. I’m sure that they would happy to help you (for a small fee, of course) if you need it before it is released.
I assume I’ll have to follow this up with PSO then. If there’s anything that can be sent to me beforehand, however sparsely documented, I’d be grateful.
How imminent is the future release with this included? Are we talking 6.5.3 timescales, or 7? What are those timescales anyway???
[QUOTE=allana;711]
How imminent is the future release with this included? Are we talking 6.5.3 timescales, or 7? What are those timescales anyway??? ;)[/QUOTE]
It’s not imminent. Several months at least is my best guess. I’ve also learned the hard way not to talk about release numbers before they are actually released, since they have a way of changing mysteriously.
I’ve been told about a “PSO Paginator” tool that comes with documentation and will exactly address our needs to both produce paged lists of snippets and publish multi-paged content items. Apparently it isn’t part of the standard PSO toolkit and we need to buy it, but it is available.
It’s a shame if we have to buy something that is going to be standard in a few months…
[QUOTE=allana;821]I’ve been told about a “PSO Paginator” tool that comes with documentation and will exactly address our needs to both produce paged lists of snippets and publish multi-paged content items. Apparently it isn’t part of the standard PSO toolkit and we need to buy it, but it is available.
It’s a shame if we have to buy something that is going to be standard in a few months…[/QUOTE]
Andrew,
Remember, that I am not the official voice of Percussion here, although I’m sure that I’m not too far off the mark (although perhaps I’m a bit blunter than the “official response” will be)
We’ve built this code and deployed it at a couple of customers in the past, but it’s not documented (well, only a little documented). There are a bunch of system customizations that are needed (a new content list servlet, for example). These all have to be added by hand (there’s no installer). There are a few consultants who know how to do this, but naturally, these people are out billing paying customers.
If we give you the code as it stands today, we’re pretty certain that you (or most other people) won’t be able to deploy this without asking lots of questions, and in some cases, having minor pieces of Java code re-written. The only way you will be successful is if we assign one of these billable resources to help you, which means that they are not working on something else. You’re in the consulting business: how likely are we to do that without you (or your customer) paying us for it?
In the next release, (a few months away), the Development engineers are cleaning up the code, integrating the changes, and removing the need for system customizations, building it into the installer, etc. The documentation team are writing a document that describes how to use it. There’s a defined schedule for these changes, and the team are working on it. They are not in a position to release “parts” of it (for example the paginator code) until the WHOLE release is finished (and tested).
So, your choice is simple:
Get one of our experienced people to help you do this (and pay us appropriately)
Wait until we’ve got it integrated and documented in the next release (and it will be free)
Is there any word on when the paginator will be released to customers?
Our next project is going to involve lists of items in the hundreds so we will obviously need some form of pagination included in the page.
I understand it was a few months down the line, but just wanted to check whether there was any further news, before I break the news to the Head of my department that he will need to spend some of his budget!
There’s still no official date for this. If I said anything at all, I’d be guessing.
As I’ve indicated here before, the consulting version of the paginator requires creating a new content list servlet and changing some internal configuration files. There are also some issues with the newest version of the Ephox control. This requires more expertise than we feel comfortable with.
The production version, of course, will address these issues, but it’s not done yet.
Apologies for dragging this up from the depths of the forum, but I understand that a paginator has been included in the release of 6.6. Is this correct?
If so, is there a maximum number of pages that the paginator will cope with? We have migrated a collection of 33,000 objects. These objects are broken down into collections, but one of these collections is over 17,000 in total. Ideally we would like to generate a list of these items with say 20 items on each page, but this would require the generation of at least 850 pages. Would the system be able to cope with this?
Regarding the scaling question, this is what the developer told me:
We did not expect to paginate this many pages, nor did we test on that scale. But the code should be able to handle it, with two caveats: first, in Content List preview, the user will see only one Content Item, but the specified number of pages will be published; second, publishing the paginated Content Item will use one thread for all pages published for this Content Item.
If the Sidebar Slot includes five Content Items, three HTML pages will be published, two each with two Content Items in the Slot, and the last page with one. Of the Sidebar Slot include eight Content Items, four HTML pages will be published, each with two Content Items in the Sidebar Slot.
How does it do this if no changes are made to the locations scheme. I have a template which correctly shows me 3 pages in preview but the content lists only shows one item. After doing a publish only one item is published as well with the pagination indicating it’s the last page.
Add the variable $sys.page_suffix to the Location Scheme to include pagination. The text describing this variable was omitted from the Rhythmyx Implementation Guide, but Figure 240 on p. 323 illustrates its use in a FastForward Location Scheme.
The text describing this variable was omitted from the Rhythmyx Implementation Guide
Any chance of having the text? I’ve added the variable to the location scheme and from the logs it’s trying to publish the correct amount of pages but they’re all overwriting themselves.
Here’s the text that should have been included in the topic cited earlier:
$sys.page_suffix Provides pagination support. If the Content Item being output is paginated, adds page numbers to the file name of each paginated page (for example, item329_2.html). If the Content Item is not paginated, or is the first page of a paginated Content Item, no page number is appended to the file name (for example, item329.html is the first published page of paginated Content Item 329, while item244.html is the only published page for unpaginated Content Item 244.
The following text should also have been included in the topic in system variables in the Bindings appendix:
$sys.page String Page number of the assembled HTML page, when the Content Item is paginated. Typically, $sys.page_suffix is used to include the page number as a suffix to the HTML file name, but $sys.page can be used for more sophisticated Location Schemes.
Used in: Location Schemes
I’ve tried added $sys.page_suffix to the location scheme, setting the value (in the bindings of the template) of $sys.page_suffix to $sys.page, using $sys.page directly in the location scheme but on each occasion the page number does not get inserted into the location scheme.
Nothing obviously wrong stands out to me in that expression, nor did it to the developer I asked to look at it.
Can you try a simpler expression and see if that works? If a simplified expression doesn’t work, contact Tech Support so we can examine your case in more detail.
If it does work, try building your expression back in increments.
