Paginator to allow Google crawl your site.

[vaibhav]

The current implementation of pagination in QCubed depends entirely on FormState. The links created for navigation onto other pages of the datgrid or datarepeaters have the 'a href' link pointing to the same page. Google cannot crawl the rest of your site that way!

I propose QLinkPaginator which creates links for the various pages (in its 'next' and 'previous' links) allowing Google to go to all the pages with paginated content. It is not the usual paginator and deals with the Request URI rather than internal object counts and hence cannot be used just as the QPaginator can be used. Along with the Crwaling possibility of all the content paginated via it, it has the following features:

Features:

*
You can set a custom 'pagination variable' For example, if you have set the pagination variable to "page" then it would create links (for page number 3) as:

yoursite.com/some/page/path.php?othervars=othervalues&page=3

If you set the pagination variable as 'list' then the query will become:

yoursite.com/some/page/path.php?othervars=othervalues&list=3

You can use the value of your pagination variable to control the content being displayed on the page (using QApplication::QueryString() function)

*
It does not remove the other variables from the URLs. So in above example, it would not remove the "othervars=othervalues" part from the URL on the 4th or 2nd page

*
A dropdown list of pages so that you can jump to the page required in one go. No need to browse to page 50, then to page 100 and then to page 122. just select the page you want to go from the dropdown list, and hit the 'go' button. It will take you there.

*
the current page number you are at is automatically selected in the dropdownlist!

*
Shows the number of results like: "Showing 21-40 out of 54 results".

*
Provides a fallback page in case the pagination variable is altered. So if someone wants to go to page 99 when there are only 98 pages, it will redirect to the 'fallback' page you set for it! So you need to write custom code to take care of that. just provide the page where you want to redirect if the value was not set right!

I hope it can be included in the 2.1 release!

[vaibhav]

QLinkPaginator Control

[vaibhav]

Err... in the last para, it should be: So you DO NOT NEED TO WRITE custom code for that.

[vakopian]

Thanks vaibhav,
Could this be used as a drop-in replacement for the existing QPaginator? If not, can it be made to be (i.e. extend QPaginatorBase)?

I can't quite decide if this is more appropriate as a plugin or as part of the core. It looks completely self-contained, so it might be a good candidate for a plugin.
Alex what do you think?

Either way, if you get a chance, it would help a lot to have an example for it.

[vaibhav]

Whether it should go to the core or be a plugin depends on the simple question:

Is providing SEO support optional?

I wouldn't be in problem if it is left as a plugin but I would really prefer it to go into the core. Someone who did not discover the plugin on the site or was unable to download it for other reason would be in loss of a very important functionality. Also, functionality as such is really important to have for a development framework (in fact, I was surprised that it did not exist in QCubed at the first place).

I did try to make it like QPaginator so that it could be easy but I could not find out a way for that. The design goals are different. QPaginator is to simply Paginate and uses FormState. QLinkPaginator on the other hand is not dependent on the FormState for most of its work (save the drop down list and the 'Go' button). It relies on processing the URL and creation of links for 'next' and 'previous' pages is the main work here. It is made to handle nuisances with URL, which QPaginator does not (and should not) care about. So QPaginator-like behavior was not really possible. I did try out things what you said, like extending QPaginatorBase or making it drop-in replacement for QPaginator but they did not work out and also, as I said, the goals of these two paginators are different and no, please do not retire/replace QPaginator - its really a piece of beauty.

I made this paginator for my own selfish purpose - to allow SEO where required and to use QPaginator where I want to not let Google go too far and I believe it should be used that way. I would prefer it going to the core (and you could move a lot of 'setter' properties to the constructor call to save a little clutter) but making it a plugin does not offend me either (anyway, it is being used my me well enough :P )

Regards,
Vaibhav

[vakopian]

Vaibhav,
Could you provide an example for this? Preferable an example similar to the existing pagination example so it could go into the main examples page.
That would make it easier to include this in 2.1.

[vaibhav]

Patch for QLinkPaginator Example

[vaibhav]

Attached it as a patch.

[vakopian]

Vaibhav,
I agree with your point about having a SEO friendly paginator in the core framework.
However I think the QLinkPaginator here, as is, is not ready to be included in the core.
So, I think you can either release this as a plugin, and prepare it for an inclusion in the core in a more mature state later, or we can continue to work on it, but push it into the next release.
Here are the changes I think would make this control a better fit as a framework component:

1. Make most of the controls (e.g. previous/next page, go button, etc) replaceable by the developer. I.e. expose them as simple properties. This will allow the developer to change these controls (e.g. instead of simple links, show buttons or images, or anything else). It would also allow them to customize aspects of controls without replacing them (e.g. css class etc). Of course the control will provide good defaults (see next point).
2. As a default for previous/next page controls, use the more appropriate QLinkButton instead of QLabel.
3. Make the Go button optional: this would allow the developer to tie the functionality to the pages drop down (so the action would be triggered on change, instead of requiring the click on the Go button).
4. Instead of making QLinkPaginator extend QControl directly, I think it would make sense to extend QPanel. In fact I think we can set AutoRenderChildren to true, and completely get rid of the html creation code in GetControlHtml(). This will allow for the same default as you currently have, but will also let the developers fully change the look of the control by using a template file for it.
5. Wherever you provide labels for any control, please wrap it in QApplication::Translate().

I started doing these changes and got half way through, but I have no time to finish it. So I'm gonna attach my unfinished (completely untested) version here. I hope you'd agree with my points above and would find my changes useful.

[vaibhav]

Those are good points. My thoughts for each of your points:

• Making them replaceable by the developer is a nice idea. I did not think about that at all! Thanks for showing me a nice way :). So when I get time, I will surely change it that way. Right now, I am very busy building things which I need to include on my site specifically. Obviously, I will give back what I feel is good for a general purpose usage for the QCubed community.

• I am against your decision of QLinkButton. As I read on its class file: {{{

/**

• This class will render an HTML link <a href>, but will act like a Button or ImageButton?.
• (it is a subclass of actioncontrol)
• Therefore, you cannot define a "URL/HREF" destination for this LinkButton?. It simply links
• to "#". And then if a ClientAction? is defined, it will execute that when clicked. If a ServerAction?
• is defined, it will execute PostBack? and execute that when clicked.

}}} So if we do that, it simply would not link to the next and previous pages and hence KILLS SEO just like QPaginator? does. It simply is the only thing you do not want in here. So I would say: It should not be done for a SEO paginator at all''. Let us not defeat the only purpose this control serves.

• The idea about removing a 'Go' button is nice but that was how I had built it originally. The point is - sometimes you might make a mistake in selecting the page number. So if you wanted to go to page number 14 and you accidentally selected 15, then you are putting an unwanted load on network, the server and wasting time. Additionally, I use a touchscreen phone and access the site I am making over wireless in my mobile at times. What I found is: some mobile browsers would not really present the dropdown list in a 'scrollable' fashion. So when you make a touch to a page number in the list (when trying to make a selection), you are actually firing a page redirection in absence of the 'Go' button. I think it should really be there. But since you have said it can be 'optional', I think it is a good idea. The developer can define the behavior he wants on site. Nice thought. Thanks :)

• This control was one of the first I wrote by myself and I was not really fluent with the way QCubed works. So I actually just took the file from examples and went on modifying it to reach here. Hence, QControl. With the changes you suggested, I think it is another wise idea.

• I think QApplication::Translate is also a nice thing. But I really do not understand the way it works (actually, I never looked in, never bothered, coz English is the only language I use / plan to use anyway). But I will do it for the sake of community. :) That is another great suggestion. :)

Now, As for the releasing it as a plugin - I am short on time again as well :( But this is one thing I believe QCubed needs vako. I would rather suggest that we push it in as an experimental feature and continue the development on the suggested lines (well, save that QLinkButton? thing). Since almost all the other things we plan to change are internal to the control and the proposed future changes would not be requiring the developer to change the code (only add some if he wants to), it can actually be pushed in as an experimental feature. Also, I believe it should not be a plugin actually. SEO is not really an 'optional' thing for most people.

Awaiting your response on this :)

Regards,
Vaibhav